Dot-notation query through multi-entity field

Flow Production Tracking
,
1

Hi,

Yesterday some artists started noticing that certain code wasn’t working anymore. In a very simplified way, it looks like this:

for element in sg.find('Element',
        [['shots.Shot.sg_episode.CustomEntity01.code', 'is', 'ep01']],
        ['shots.Shot.sg_status_list']):
    print element['shots.Shot.sg_status_list']

Unsurprisingly for me, it raises a KeyError. I didn’t write this tool— I’ve always thought querying through a multi-entity field using dot notation never works because the relationship isn’t 1:1 (i.e. an Element could be linked to more than one Shot), but the artists insist that this was working earlier this month.

I’ve tested it with Python API versions 3.0.32 (which we were using in March) and 3.0.37 (which we’re using now)— no dice. Is it possible that an update to Shotgun itself has altered this behaviour?

Thanks in advance,
Unai

2 Likes
2

Okay this is a bit absurd now. Further down the code, there’s this gem:

    shot_code = element['shots.Shot.sg_status_list'][0]['name']

Which makes me think that, maybe, when you asked SG for multi_entity_field.Entity.field before, it would give you the same result as querying multi_entity_field alone, but now it simply ignores it? Is this possible?

2 Likes
3

Hi Unai,

In the 8.17 release we began more strictly enforcing the way bubbled fields (dot notation) data is accessed. In your example, do the artists running the code have the permission to see each entity and field contents along the entire chain (i.e. can they see sg_episode , CustomEntity01's, and the code field on those entities?)

1 Like
4

Hi Brandon,

Yes they can. Plus, I can confirm that the filter ['shots.Shot.sg_episode.CustomEntity01.code', 'is', 'ep01'] is not a problem at all, neither is querying for shots directly. However, when querying for shots.Shot.sg_status_list or similar, it’s guaranteed that the resulting dicts won’t have that key in them.

2 Likes
5

Thanks for checking the permissions. I’ll ask the rest of the team here to see what I may be missing as part of the equation.

1 Like
8

Hi @Unai,

Jumping in here to share with you what tech experts explained. Check this post from Pat.

Specifically, that you can’t link through multi-entity fields to get a specific result:

You should know, however, that you can’t use linked filter syntax in a field list if one of the links in your path is a multi-entity link. By definition, a multi-entity link you hop through would have to follow multiple paths and there’s currently no way to reflect that in a result set.

For example, in the following, it would be impossible to flow through all tasks to return multiple statuses:

shots = sg.find('Shot', [['id', 'is', 1234]], ['tasks.Task.sg_status_list'])

4 Likes
9

Thanks guys, that makes perfect sense.

What the code I fixed yesterday suggests though, is that before 8.17, the shots variable in your example would be:

[{'type': 'Shot', 'id': 1234, 'tasks.Task.sg_status_list': [
    {'type': 'Task', 'id': 123, 'name': 'aTask'},
    {'type': 'Task', 'id': 456, 'name': 'anotherTask'},
    ...]}]

While after 8.17, it’s:

[{'type': 'Shot', 'id': 1234}]

Can we confirm this?

1 Like
10

I’ll take the silence as a yes.

11

Hey Unai,

Sorry for the radio silence here. We’ll check with the engineers and report back.

13

Hi Unai,

Just spoke with the engineers, and here’s what I learned. With the more strict enforcement of how data is accessed through bubbled fields, this is indeed a result of that. You never could request the bubbled task status through the tasks.Task.sg_status_list field, but it looks like we (incorrectly) were returning a Task list anyway. You can still get this result by requesting the tasks field if you need that list of Tasks.

I apologize if you were reliant on this shortcoming and it changed out from under you. Glad to hear you were able to make a fix, though.

2 Likes
14

Makes complete sense Brandon. Thanks for clarifying! :blush:

1 Like