Calculated fields not triggering event in shotgun daemon

This may be a bug or a feature:
calculated fields do not seem to show up in the event log when their value changes, and thus cannot trigger shotgun event daemon plugins. In my case this is ok as the cal;calculated field in question only involves two other fields (which I can use as triggers for my custom plugin directly), but just wanted to raise this to see if it’s a deliberate design decision or an oversight?!

Cheers,
frank

2 Likes

If this is intended behaviour, then I’m curious about if there’s a possibility of the Event Daemon firing off too fast for the calculated field to update.

I’ll explain with an example. On our Shot entities, we have Cut Duration that counts the number of frames in a Shot. We’ve also made a calculated field “Length”, which basically calculates the length of the shot in seconds, based on the Cut Duration.

Say we have a trigger that will post a note saying “Scene has been updated to Xs long.” that triggers when the Cut Duration is updated and uses the “length” of the shot. So the intended order of operations is:
Cut Duration Updates > Length Updates > Note posts

But is it possible that the calculation is delayed, leading to:
Cut Duration Updates > Note posts > Length Updates
which would mean the note posted with an incorrect length since it hadn’t yet updated.

I expect that this is at least unlikely because the event triggers running on our server should be slower than the calculated field. But is there a gap where this could theoretically possible? Particularly if there’s slowness on the databases end?

1 Like

Hey @frank, I’m not sure whether this was by design or not, but I think like @Gary says, the main concern here would be race conditions and potentially triggering the same behavior from multiple places. You could have something acting on the source fields changing, then something else firing from the calc field change that is counteracting the first trigger.

That said, would be happy to hear any critical use cases people may have to introduce more logging here.

3 Likes

Thanks guys. In my case it’s not critical.
Due to calculated field’s inability to compare linked entity fields (as mentioned in another thread), I am using the event daemon as a workaround to colour code versions who’s frame count does not match their parent shot’s working duration.
When setting this up I was trying to react to a shot’s working duration field, which in our case is a calculated field. This is when I noticed that there are no event logs from calculated fields to react to.
Easy workaround though, as the calculated field only references two other fields, so I made the event daemon react to those instead.

Cheers,
frank
As mentioned

2 Likes

Hi Frank,

Rather than say it’s a design choice or an oversight, can I say it is a current limitation? :wink:

The implementation is such that the value of a calculated field is computed at read time and isn’t stored or cached in the database. This leads to two things:

  • When source data for the calculation changes you don’t get an event for the calculated field because the calculated field isn’t computed at this time but will be computed later when read. We also don’t keep a registry of computations that would allow us to know which “fake” events to log in the system because a source field changed.
  • When you read a calculated field, you’re guaranteed that the output will be valid for the current state of all other data in the system. There’s no case where you can edit field A which is used as a source in calculated field B and field B would be lagging. So your trigger on field A change would read valid data on field B.

So I guess that’s one negative and one positive? :grimacing:

Anything to add or correct here, @antoine.hebert?

4 Likes

That all sounds fair enough to me, thanks for clarifying.

3 Likes

Sorry @bouchep, this landed in my Junk Mail…

You’re right, calculated fields are computed at read time. So it would be hard, with the current design, to trigger an Event.

2 Likes