Store and lock the "family" on a "subset"

[BigRoy]

Discussion

We've been having the need to filter for an asset the available "looks" (specifically the latest versions) and list them to the artist. Currently there's no way, by subset, to know whether it contains a specific family so it requires.

To me personally, a subset is a specific family, and during its lifetime of existence it shouldn't change to house any versions of a different family. For example subset lookDefault would never get a version of family model if the first version was a look family, I would disallow it changing the family over its lifetime.

Problem

Currently listing all latest look families requires something along the lines of:

subsets = io.find({"type": "subset", "parent": asset_id})
looks = list()
for subset in subsets:
    versions = io.find({"type": "version", "parent": subset['_id']})
    has_look = any(x for x in versions if x['data']['family'] == "look")
    if not has_look:
        continue

   looks.append(subset)

print looks

Still, this would also allow that the subsets returned might possibly contain different families than a look. So one of the versions in the subset could in practice be a camera family or model family.

By locking the subset to a specific family the subset presents itself more clearly to the artist, directly, plus it persists over time. Additionally this simplifies listing the looks for an asset to:

looks = io.find({"family": "look", "type": "subset", "parent": asset_id})

What do you think?

[mottosso]

Thanks @BigRoy.

I read two problems here.

1. Finding versions by family is hard
2. Families should be stored in subset, not version

For (1), you could use the $in operator.

# All versions of family "mindbender.rig"
io.find({"type": "version", "data.families": {"$in": ["mindbender.rig"]}})

For (2), sure. That makes sense. Could we make it families though, as opposed to family?

[BigRoy]

For (2), sure. That makes sense. Could we make it families though, as opposed to family?

We could, sure. @aardschok what you think?

[aardschok]

Perfect, enables a more broader search too!

[BigRoy]

@mkolar could this introduce issues with how you are handling "Review" currently - that can be embedded within a specific publish, e.g. a review included with a pointcache - correct? If so, does that change the "families" of that subset? (Like does it append that family for a specific publish, or what's your use case?)

[mkolar]

For reviews specifically. we add review into families of the given subset, which triggers review extractor and attaches the quicktime as another representation.

Across the board we use multiple families on many things during publishing. We then only store the main family on the version in the DB as all the additional ones are irrelevant once they've been extracted.

[BigRoy]

Across the board we use multiple families on many things during publishing. We then only store the main family on the version in the DB as all the additional ones are irrelevant once they've been extracted.

Ah, interesting. So it containing a review family is not added in the database? :) How do you query all reviews?

[mkolar]

If a subset contains review family, it gets added to database with review mov as one of it's representations.

If review gets collected as an instance on it's own (we do that when review is task based rather than subset based), it becomes it's own subset in the db and on ftrack.

example A. Bob -> Modelling
subset: modelMain
familiy: model
families: model, review, ftrack
results in representations: abc, ma, mov, jpg
review mov appears in ftrack as a component on an asset (subset in avalon terms) named modelMain v01

example B. sh010 -> Animation
subset: reviewMain
family: review
families: review, ftrack
results in representtions: mov, jpg, and ireview mov appears in ftrack as it's own asset named reviewAnimation v01

[BigRoy]

@mkolar I'm wondering, are you already storing the families on the subset, or still storing it on the versions? I'm thinking about how we could implement this specific one without breaking backwards compatibility. :)

[davidlatwe]

Re-enter this topic :P
Has anyone resolved this ?