Why does "something" in path_cache not return results?

Pipeline Integrations
1

Why does the api not return results for this?

filepath = “G:/Projects/__SGToolkitMasterConfig/shots/episode1/TST_0010/lighting/out/TST_0010_comp.v044/1920x1080/TST_0010_comp.v044.%04d.exr”

filters = [ [“path_cache”, “in”, filepath] ]
print sg.find_one(“PublishedFile”, filters)

Returns None

while

filepath = “__SGToolkitMasterConfig/shots/episode1/TST_0010/lighting/out/TST_0010_comp.v044/1920x1080/TST_0010_comp.v044.%04d.exr”

filters = [ [“path_cache”, “in”, filepath] ]
print sg.find_one(“PublishedFile”, filters)

Returns a result

Seems like “in” is not evaluated as it should?
Seems like it “in” evaluates as “is”…

1 Like
2

Hmm, I’m not sure my self. I know from a Python perspective you would expect it to check through the string, but I’m not sure about PSQL.
Does ends_with work for you instead?

2 Likes
4

Hi Ricardo,

The in isn’t a construct that directly translates to our database backend, it is a Python API construct. In this case, the in will indeed perform like an is. The in relation isn’t about seeking a PublishedFile record whose path_cache value has a substring matching filepath, it’s more about being able to supply multiple values on the right-hand side of the in. For example:

>>> p1 = 'some/relative/path_v001.mb'
>>> p2 = 'some/relative/path_v002.mb'
>>> len(sg.find('PublishedFile', [['path_cache', 'in', [p1, p2]]]))
2

Each right-hand value is evaluated in a == fashion with PublishedFile records and will allow for multiple matches on multiple values.

The only substring matching operators we have, as @philip.scadding mentioned, are starts_with, ends_with and contains. I wouldn’t necessarily suggest these if you have alternate ways of finding your content because on extensive datasets, they can be slower.

For reference, here is our doc on filter operators and arguments.

4 Likes
5

ends_with seems to work :slight_smile:

Thanks all!

1 Like