Re: [Tiki-users] A good way of representing record subtypes with trackers

Hi Bernard,

Thanks for your answer. I like the option of storing event details in
separate trackers, but I think it makes some queries tricky. That's
probably because I do not have much experience with Tiki).
For example:
each event has field "source host" stored in tracker "Common event data";
a key press event has field "key" stored in tracker "Keyboard events";
the two tracker are linked.
How do I search all key presses of key 'a' received from 'myhost'?

Thanks,
Ilya

On Sun, Feb 28, 2021, 02:28 Bsfez Tiki via TikiWiki-users <
[email protected]> wrote:

> Hello Ilya,
>
> I would first evaluate the "next " steps because the answer to your
> question depends of the big plan (and its size). ;-)
>
> Putting all in one tracker is easier to create but can turn to be too
> dense for an easy "user" items management.
>
> Having several sub-trackers offer better flexibility and granularity
> settings (like permissions screens, status, etc).
>
> Not having to read/load all the item fields values for sorting or
> reporting also help (as I experienced) in term of load and speed page.
>
>
> How far you want to split… hard to say (how many items, events expected ?)
>
> Raw answer, I would go for your last option :
>
> > Define one tracker for common fields, one tracker per class for
> > class-specific fields and link the trackers via item links.
>
> Bernard
>
>
> > On 27 Feb 2021, at 10:10 , Ilya Perminov <[email protected]> wrote:
> >
> > Hi,
> >
> > Imagine we want to represent some events using trackers. Each event
> > has event class, event timestamp, maybe some other common fields, and
> > some fields that are specific to its event class.
> > The classes can be  key press, mouse click, timer event, etc. For a
> > key press we want to store which key was pressed, for a mouse click we
> > want to store a mouse position, for a timer event a timer id, etc.
> > What is a reasonable way of doing this?
> > I can think of 3 options:
> > - Put all events to one tracker that has a union of all fields from
> > all event types. Hide/show class-specific fields based on the selected
> > event class, probably using rules. This seems a bit hard to maintain,
> > e.g. if there are 5 class-specific fields for each class and 4
> > classes, I'll have to define 4 rules with 20 hide/show commands each.
> > Plugin JQ may help, but I am not sure how to inject it into a standard
> > tracker item editor.
> > - Define a tracker per event class and give the common fields the same
> > names in all the trackers. Plugin List can fetch items from multiple
> > trackers, so it may work, but I think it is a bit hackish, and plugins
> > that take only one tracker will not be usable.
> > - Define one tracker for common fields, one tracker per class for
> > class-specific fields and link the trackers via item links. This is
> > how one would do it in a SQL database, but I think doing joins in
> > TikiWiki is not that easy.
> >
> > How do people usually handle something like this in TikiWiki?
> >
> > Thanks,
> > Ilya
> >
> >
> > _______________________________________________
> > TikiWiki-users mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/tikiwiki-users
>
>
>
> _______________________________________________
> TikiWiki-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-users
>

_______________________________________________
TikiWiki-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-users