0

Missing entity on change-event for retirement_date before retirement

Thomas Bach

February 04, 2010 14:33

None

Follow

Hello

I am currently working with API-Events and I'm experiencing some strange behaviour. Before a retirement-event is fired, a retirement_date change is fired but without any information about the entity affected:

The retirement_date-change event looks as follows:

{'attribute_name': 'retirement_date',
 'entity': None,
 'event_type': 'Shotgun_PublishEvent_Change',
 'id': 23091,
 'meta': {'attribute_name': 'retirement_date',
          'new_value': datetime.datetime(2010, 2, 4, 11, 53, 35, tzinfo=<shotgun_api3_preview.LocalTimezone object at 0x153bd50>),
          'old_value': None,
          'type': 'attribute_change'},
 'type': 'EventLogEntry'}

For this event I don't have any possibility to get the corresponding entity. The event is then followed by the following event:

{'attribute_name': None,
 'entity': None,
 'event_type': 'Shotgun_PublishEvent_Retirement',
 'id': 23122,
 'meta': {'class_name': 'PublishEvent',
          'display_name': '016',
          'id': 20,
          'retirement_date': datetime.datetime(2010, 2, 4, 11, 53, 36, tzinfo=<shotgun_api3_preview.LocalTimezone object at 0x14b3d50>),
          'type': 'entity_retirement'},
 'type': 'EventLogEntry'}

Do I missunderstand something or is there a bug in the event trigger? I assume that this is for some concurrency control but I for some reason don't get the point ...

Kind regards,
thomas

• Facebook
• Twitter
• LinkedIn

2 comments

• 0
  
  Isaac Reuben February 04, 2010 21:26

  Thomas,

  This is a catch-22 in our retirement events which was introduced when we refactored the way the api gets it's data.  It used to be that the api was getting data through a side band (not going through the regular path that data to/from the browser takes), but we've updated it so it all uses the same methods (which adds a number of new features to api, and reduces future bugs because all use the same code).  But...  That other data path has a hard restriction on not showing things that are retired -- it acts as if the thing was really deleted completely, to make sure it doesn't pop up anywhere accidently in some place that isn't filtering out retired data.  But it also filters it out when reading these two events, so the "entity" field is just showing None!  =/  

  So we need to add an exception to allow reading the value of event log entries, even if that entity has been retired.  We have a ticket for that, and is scheduled soon.

  As an aside, we're going to be testing out another method of watching the event stream that uses a queue (AMQP, using rabbitmq specifically) to dispatch the events instead of reading them from the database through the API.  This has a few benefits over reading in the api (faster notification of events, actually *consuming* events so ones that have been dealt with don't need to stored, works around some tricky issues with events that were created inside transactions).  This queue method would also work around this, because the event info would be written to the queue before the entity is actually retired.

  Cheers,

  - Isaac

• 0
  
  Thomas Bach February 08, 2010 08:35

  Thanks for the quick response! It makes much more sense now. Looking forward for the new versions, the AMQP sounds interesting.

  Forgot to mention that it is a pleasure to work with (and develop around) shotgun. Looks like there are great coders behind it! Keep going!

  regards,
  thomas