Timings: 'tags' and 'event' keys for workload 'events'

[mturilli]

In a timing session, workloads events are stored as:

{u'time': datetime.datetime(2014, 2, 17, 5, 0, 11, 103000), u'event': u'timed_create', u'tags': [u'wl.0001']}
{u'time': datetime.datetime(2014, 2, 17, 5, 0, 11, 104000), u'event': u'state', u'tags': [u'Described']}
{u'time': datetime.datetime(2014, 2, 17, 5, 0, 13, 65000), u'event': u'state', u'tags': [u'Translated']}
{u'time': datetime.datetime(2014, 2, 17, 5, 0, 14, 250000), u'event': u'state', u'tags': [u'Bound']}
{u'time': datetime.datetime(2014, 2, 17, 5, 0, 17, 947000), u'event': u'state', u'tags': [u'Dispatched']}
{u'time': datetime.datetime(2014, 2, 17, 5, 1, 30, 57000), u'event': u'state', u'tags': [u'Done']}

The key 'event' seems to be used to store the type of event - state (transition) - and 'tags' to store the name of such type - e.g 'Described'. Would it be possible to use 'event' to store the name of the event as done in the first entry? This would also free the possibility to use tags for multiple annotations of the named event.

[andre-merzky]

I'd rather change the first entry to event: state, tags: ['New']. This way it will be easier to filter for event types (we only have a few right now, but I assume we will have something like state, notification, input etc. in the future). But if tags as a list is too inconvenient to handle, we can add a name or detail or something and put the actual state information in there?

[mturilli]

List is fine to handle and I have code already written to do it. My concern is to use a list for an entry that needs just a string. I like your suggestions of having a 'name' field where to store the name of the event type while leaving 'tags' free for whatever tagging we will like to do in the future.

[andre-merzky]

ok! :)

[andre-merzky]

event names are now implemented.