"Subclassing" entities

Flow Production Tracking
, , ,
1

Hello everyone!

Inspired by USD, I’m testing organizing a project in two main entities: components and assemblies.
Components would be any item that can be published and that has no intrinsic dependencies (ie Meshes, Textures, Skeletons, Cameras, Lights, Images, or any relevant item that is worth keeping track of), whereas Assemblies would be meaningful “collections” of components and/or other assemblies (ie Models, BlendShapes, Rigs, Scans, sets of renders, and so on).

So, at the moment I have these two entities, and each one of them has a ‘type’ list field used for sorting/filtering.
It would be ideal (if not critical in some cases) to have specialized entities for some of these types, however since there is no option for a “Multi-Entity” filed type that allows multiple entity types, I am forced to use one generic Component entity: specifically, I can only choose either a Multi-Entity field which can only have one Entity type, or an Entity field which allows several entity types but only one item at a time.

Additionally - if I were using specialized entities for some or all my Assemblies - I wouldn’t be able to filter by fields that belong to the Assembly entity, even if I created fields with the same name on my specialized entity.

In programming terms, I’d like to somehow “subclass” entities, so that all subclasses shared the same interface (=fields). And I could then add BaseClass-type fields where also subclasses are accepted. And I could then filter using fields from the BaseClass from the “Linked Entities” section. Basically I would like to leverage the Liskov Substitution Principle of OOP, and be able to treat any subclassed entity like the base class. :eyes:

I know that Shotgun is not designed to work this way, and I am not expecting any change in this sense. However I was wondering if anyone could recommend a good approach to this scenario.

As I said, I’m still in a testing phase, trying to find compromises between what I have in mind and what is possible with the current technology. Just to say that this is just a proof of concept, and might change very much very quickly.

I’m looking forward to hearing your ideas!

2 Likes
2

Hello!

I’ve been thinking about this, and I thought that a potential solution could be to create a separate specialized entity with all its entity-specific fields, and link it to the corresponding BaseClass item.

So for instance if an Assembly type Scan needed extra fields like “talent”, “scan_nr”, “calibration”, etc, I would define a new CustomEntity “Scan”, add the required extra fields, then create an entry for “jawOpen” and link that to my jawOpen Assembly.

This should allow me to both have a generic Assembly entity that can be used in Multi-Entity fields, and to add and access fields which are specific to an assembly type.

However this solution adds a huge amount of work to setting up and maintaining a project, and introduces duplicate/similar entities that can lead to confusion.

I’m not sure this is a viable solution, but it’s the only one I could think of for now.
It would be great to have somebody else’s input on this!

Cheers!

2 Likes
4

Hi @nonlosao,

Unfortunately, as you’ve already stated, there’s no perfect way to address this in Shotgun without a proper, custom, polymorphic multi-entity field.

Your approach of having a single piece of information broken up into 2 distinct data records in Shotgun, some data living in a base record that links out to a class-specific record for the remaining information, is sensible.

The overhead for project creation and record management can largely be taken care of with automation and data management tools.

I would highly recommend getting a thorough understanding of the purpose of your custom fields that would live on the class-specific record. As I see it, there are pieces of information valuable to Shotgun’s UI experience that would require their own fields as they allow for filtering, sorting, grouping and navigation. Other pieces of information are just read-only by your toolsets and use Shotgun as a simple repository. This latter type of information could easily be bundled in a serialized data format and live in the base class record. There is even somewhat of a precedent in Shotgun in the EventLogEntry.meta field. You might discover that some derived record class types might not be necessary because all their information can be stored in the base class’ serialized data bucket. In this case, the list field in the base class, which I’d keep, would be enough to define what you’re looking at and what to expect in your serialized data field.

The above would potentially simplify your schema.

Good luck with your project!

2 Likes
5

Hi @bouchep,

Thanks for getting back to me.

I agree with you. I wouldn’t create fields for every single piece of information I need to attach to an entity. The data bucket approach sounds interesting, and I was thinking about something similar too, but I wasn’t sure if it was possible in SG.

I had a quick look at the available field types, and I am not really sure how I should approach this.
Should I use a File/Link field type and point it to a file on disk? Should it be a File entity type? Or what do you thin the best approach for this would be?
Is there any link or tutorial you can share with me that explains how to do this?

1 Like
6

I don’t think we have specific docs or tutorials.

The simplest implementation would simply to create a text field and drop some JSON or YAML or similar data format in it.

1 Like