Representation: Support for trait-based representation.

[antirotor]

Story

With the move to the new representation model, we need to change a little bit how it is handled in backend. New representations are basically lists of traits - pydantic models that describe "the nature" of the representation itself. More info here and here. But in essence, those traits are serialized to dict/json like this:

{
        "ayon.content.FileLocation.v1": {
            "file_path": "/path/to/file",
            "file_size": 1024,
            "file_hash": None,
        },
        "ayon.2d.Image.v1": {},
        "ayon.content.MimeType.v1": {
             "mime_type": "image/jpeg",
        },
}

Proposal

We could introduce new column trait and store these there to keep "data" for more generic purpose. Then there is files column that will be superseded be Traits holding basically the same data. So my proposal is (when retrieving this data) search in traits, if not there, search in files column.

Further notes

Since Representation Traits are very dynamic in nature - core set defined in ayon-core, but every addon can define its own traits. So available traits set is based on current bundle of addon. There could be backend support to get schema of all available models for example. But the value of it is yet to be determined. New representation traits will allows some analytic work on AYON frontend - queries like "get me all published images larger then 2K" etc.

[BigRoy]

Just wanted to comment that we're likely better of storing the "version" of the data inside the data of each entry, like e.g.:

{
        "ayon.content.FileLocation": {
            "file_path": "/path/to/file",
            "file_size": 1024,
            "file_hash": None,
            "__version__": "1"
        },
        ...
}

Just so that if you wanted to check whether the dict has a trait that you don't need to "look for any matching version" but you can do the O1 lookup in the data instead?

---

Since Traits as pydantic models are very dynamic in nature

They are actually the opposite. The models are very static/typed and clear - not dynamic. I suppose you're referring to the fact that something can have any combination of traits which is what makes it dynamic. But that's not due to pydantic itself?

[antirotor]

I suppose you're referring to the fact that something can have any combination of traits which is what makes it dynamic. But that's not due to pydantic itself?

Yes, sorry. Pydantic models of individual Traits are static, but their combination in representation isn't.

Regarding version: that is already part of the concept - how - that is still matter of discussion (but not here, as this should "just" add column to database) but rather here