SG trigger meta contents

Flow Production Tracking
,
1

What determines the values that are part of the meta being passed in to a trigger? If I wanted a specific property (Project.sg_type) to be part of the meta in every trigger, is that something I can control?

5 Likes
2

Hey @mharris!
I think I know the answer to your question, but before I answer, I want to be clearer about what you mean by ‘trigger’. Are you talking about the metadata in an EventLogEntry record? (e.g. the 'meta' field pulled for events for the Event Daemon?)

1 Like
3

Hi @tony,

Sorry for my vague generalization, I was typing this question from the couch where I had no access to code base for exact examples…

Yes, when registering a callback with the event daemon you get an event. Which has information about what is being monitored. From there I can run event.get('meta') to get the dictionary of data with more info like the entity_id and entity_type. Now that I am looking at code it would not be part of the meta that what I am looking for would be. It would actually be part of the event. To get the Project name I could use event.get('project').get('name'). I would like to also be able to do something like event.get('project').get('sg_type') to get the Project type.

Basically I am trying to avoid the need to execute:

project = sg.find_one('Project', [['name', 'is', event.get('project').get('name')]], ['sg_type'])
project.get('sg_type')

…inside my code.

2 Likes
4

Nah, no worries. Everyone’s got their own headspace for terminology, it’s what keeps things interesting sometimes :smiley:

  • Unfortunately: You can’t alter the kind of information that winds up in the EventLogEntry records, but…
  • Fortunately, the project field is a native field for EventLogEntry (and is usually populated if relevant).
  • Unfortunately (again), you only get type and id for the project.
  • Fortunately (again), type and id are all you need to uniquely identify anything in Shotgun.

Ultimately, this won’t help you avoid the call you’re talking about, but if efficiency is what you’re after, you can make it marginally faster by querying by type & id instead of name, since that obviates a text search at the db level.

proj_id = event.get('project')['id']
project = sg.find('Project', [['id','is', proj_id]], ['sg_type'])
project.get('sg_type')

Something else you could consider, since I don’t know what you’re after, is that since Projects don’t change often (or at least, they don’t often change often, I guess it depends on the studio), you could:

  • query all your Project metadata (generally this would be a smallish amount of data)
  • cache it
  • update it when you know the cache is dirty
  • you can pull the project info from the cache when trawling events, instead of having to do extraneous sg_find calls.

Just food for thought, I don’t know your setup :slight_smile:

I hope that helps, let me know.

6 Likes
5

Also, I’m gonna real quick move this into #shotgun from #pipeline, since it’s more about the API than SG Toolkit.

2 Likes
6

Something came up in discussions yesterday and I wanted to clarify by asking you guys directly… Exactly how many times and how often is the registerCallbacks method of a SG event called? Is it only called once when the daemon is started up/broken script fixed, or is it called every time a monitored event is found and triggered? At the time the registerCallbacks method is called, is there any connection to a Shotgun instance or would you have to make a connection via shotgun_api3 if you wanted to do a sg.find(…) call inside the registerCallbacks method?

3 Likes
7

The registerCallbacks method is called once at every plugin load. That means once when the daemon is started as well as once every time the plugin is reloaded after a failure (if a plugin fails it is unloaded and if you change the code and save the file, the daemon will try to reload it at which point it’ll re-call registerCallbacks).

While in registerCallbacks, you do not have access to a Shotgun connection supplied by the daemon because you haven’t yet provided credentials to create the connection, which you’ll be doing by calling reg.registerCallback(). You can create your own connection by using shotgun_api3 and using the aforementioned credentials. Just remember it’ll only run once.

This can be useful to load some initialization state from Shotgun and then pass it on to callbacks via args like in this example:

One example could be to load some chunk of Shotgun schema which your plugin would rely on for some sort of introspection. You definitely wouldn’t want to load the schema every time the plugin callback runs so you could load it at registration and cache it.

3 Likes
8

Thanks @bouchep!

That is what I was curious on. Here they have code using args to store studio specific data that I have never seen done before. Did not know this method was called only one time when the daemon/script is started/restarted. Do you have any examples of loading and caching the SG schema to then be passed in to the callback via args?

1 Like
9

I don’t think we have any examples of this on hand; it’s possible that one or more of the plugins in the examplePlugins directory might do this, but I don’t think it’s likely.

2 Likes
10

Alright, I was just wondering if it was documented anywhere. I am sure that @scottballard is doing this someplace in his Shotgun Schema tool. I will just have to poke around in there to see how/if this is being done.

1 Like