Add Variant Class

[eoyilmaz]

User Story

As a supervisor I want to be able to approve individual variants a Task so that when I approve the Task I now that I approved a certain variant and not the whole Task.

Acceptance Criteria

• Derive a new class called Variant from the Task class.

[eoyilmaz]

Let's do some brain storming:

• Task dependencies affect their statuses.
• If we start adding statuses to Versions, how are we going to handle Task statuses?
• Should we decouple Version and Task statuses.
• Or should Task statuses be defined by a combination of their dependencies and Verisons?

I think it is better to do a mindmap about this issue.

[eoyilmaz]

Incredible... I love mind mapping...

So, the result of my mind mapping session is that we should not make Verison instance statusable, but attach them to the Review class, so that they are part of the review process.

Because, we can reach the related Task from the particular Version instance that is in the review, we might change the Review class to store the Version.id instead of the Task.id. But, then this would limit and force us to always use Versions for reviews which some times is not desireable.

Let me keep mapping my mind.

[eoyilmaz]

Okay, I quite like the idea of adding a new mapped attribute to Review class to relate it with a Version instance. So that we can attach a specific Version to a Review and reflect the Review.status in the UIs along side a Version. This is solving all our problems in a very elegant way that is both back compatible and opens up a plathora of new options. Let's update this issue.

[eoyilmaz]

Oh, re-reading the issue "User Story" I realise my original intention was to also distinguish individual variant approval statuses (takes in old terms). Because we are attaching a Version to the Review, we'll also be carrying the variant_name information along with it, but when the Review is approved, it will update the task status again, and all the other variants are going to be approved together.

Let me investigate this further.

[eoyilmaz]

So, after thinking about this whole day long, I came up with a seamingly brilliant idea of creating a new class called Variant, which is deriving from Task.

To list all the things to do this properly:

1. Create Variant class deriving from the Task class.
2. Remove Version.variant_name.
3. Add Review.version mapped attribute.

Use the new Variant class in Task hierarchies, here is an Asset hierarchy example

Char1 (Asset)
    Model (Task)
        Main (Variant)
            Version(version_number=1, extension=".ma", created_with="Maya 2025")
            Version(version_number=2, extension=".ma", created_with="Maya 2025")
            Version(version_number=3, extension=".ma", created_with="Maya 2025")
            ...
        Broken (Variant)
            Version(version_number=1, extension=".ma", created_with="Maya 2025")
            Version(version_number=2, extension=".ma", created_with="Maya 2025")
            ...
    LookDev (Task)
        Main (Variant)
            Version(version_number=1, extension=".ma", created_with="Maya 2025")
            ...
        Red (Variant) (depends_on=[Model->Broken))
            Version(version_number=1, extension=".ma", created_with="Maya 2025")
            ...
    Rig (Task)
        Main (Variant)
            Version(version_number=1, extension=".ma", created_with="Maya 2025")
            ...
        WithCloth (Variant)
            Version(version_number=1, extension=".ma", created_with="Maya 2025")
            ...

This way we can track the dependencies of individual variants to each other, and make the "variant" a direct information instead of being an indirect information where it is gathered through the unique values of Version.variant_name attribute of a Task.

I'm very happy on how this is solving all the problems we were having with the Tasks, Versions, dependencies and Reviews etc.

Let's sleep on this.

[eoyilmaz]

Further thinking about this topic, one interesting question is about the "Version Representations".

In Anima Pipeline we were encoding the Version.variant_name to store different representations of the same, let's say, Maya scene. For example we had a Version with variant_name of "Main@RS" to store the Redshift Proxy version of the same scene, and maybe a "Main@ASS" representation for the version that is gathered with the Arnold Scene Source's of the same objects. So, we were basically encoding a logic with the "@" sign there.

Now, as the Version.variant_name attribute is getting removed with the introduction of the new Variant class, this is not going to be possible anymore.

One solution to this (also this is another thing that resolves into another huge topic) is to use something like a Stalk to Leaf relation of DNEG pipeline. That is, to remove Version instances from being the representation of the Main representation, and make them akin to DNEG Stalks, and store everything as Link instances with types like DNEG Leafs.

So the Main file will be a Link(name="Main", type=Type(name="Maya Ascii Scene")) and the RS representation wiil be a Link(name="RS", type=Type(name="Redshift Proxy")).

And make the Version no to be deriving from Link at all, but from Entity, removing the ability to store files...

We can keep deriving Version from Link class. That's totally okay. And it has parent/child, input/output relations (which at DNEG we didn't have, we only had seeds/pods relation which is used to describe kind of the input/output relation, where it created a huge problem when I used it as a parent/child relation descriptor).

Anyways, so the solution is to store the representations as Link instances and not Version instances, save the native scene file of the DCC as a Link with Type=Main.

This doesn't require any change on Stalker side.

[eoyilmaz]

This seemed to be a huge work to handle in a single issue, so I moved some of the work to #120 and #121, and along with #119 these changes makes more sense.