Reading through the glossary, I find a bit hard to understand the relationship between Task and Product, or more specifically between Task Types and Product Types, I understand that a Product is some data being published for a given Folder, and that it has both a Product Type and at least one Representation, but isn’t that the same as saying that a Folder has Tasks and that Tasks have Task Types and that a Product is a publish of some specific Task data? If that was the case we wouldn’t need the Product Type as it would be implied in the Task Type.
Is there a relationship between Task Types and Product Types?
As far as I know,
Each folder has one or more task(s).
From each task you can launch one or more Host(s)/Applications.
Each host has one or more creator(s) plugins.
Each product type can be created by one or more creator(s) plugins. (we can have two creators to create the same product type.)
I think we should be able to filter Host(s) options based on task type.
we filter creator options based on Host.
and, we can’t filter creator options per task type directly.
So, the Product Type as it would be implied in the Task Type. is not accurate.
Mentioning @iLLiCiT, he can provide much better answer.
I still find it a bit confusing. This would mean that -depending on how the project is set up- I could potentially launch a model Task and publish a rig Product right? Then what is the purpose of a task exactly? having control over the environment that is created in the host and or GUI capabilities like filtering hosts?
Is it enforced that a version can have a relation to a task? can you provide me with an example of why would there be a relation between a version and a task and why not?
I can imagine that the reasoning behind this setup is so that you can have both Tasks without Products or as you say, having two tasks commiting to the same Product Type, in a way that, for instance Model and UVs can be tracked separatedly and both produce just on Product Type? is this correct?
yes, this is possible at the moment as far as I know.
The thing is task and product naming is similar but they are not always the same.
e.g. I can have a FX task with many product types vdb, pointcache and etc.
If I got you correctly, you want to control which product types are allowed to be published within a particular task type ?
Thank you for your answer @mustafa_jafar, at the moment I am just trying to undestand how Ayon’s database schema works so to speak, as well as the reasoning behing that schema; I find a few definitions in the docs to be either a bit misleading or scattered through out a bunch of diferent doc pages (I have already opened another post with ideas on how to improve this).
I come from a background where Tasks and Versions are tightly coupled, so this paradigm is new to me, and I need to understand it correctly.
I guess that a maya file, under a Model Task, may create 2 Products: Model_low and Model_high, for instance, right? I still see a link between tasks a products tho, because you will most likely use certain tasks to create certain host’s environments that will lead to certain Products, so when @iLLiCiT say that Tasks and Products are not related I imagine he means relation as in a relation in the postgreSQL database, not as in workflow relation right?
Do tasks in Ayon still are an assignment unit? or are they just “working environments”? Here it doesn’t say anything regarding tracking, but I find this somehow problemating when integrating external tracking services like Shotgun/Shotgrid/Flow Production Tracking and Ftrack, where Tasks are kind of a building block for tracking purposes.
By the way, would a Maya Playblast of a turnaround be also a Product Type fo “render” with a Representation being the video file itself?
I would say that you have to understand that whatever we’ll answer now, doesn’t mean it will be same in a year. We just started to switch from OpenPype to AYON. OpenPype tasks were not really considered as entities, so there is massive amount of logic that does not consider tasks as entities. Tasks were used to “create” the product name, or as fill data for templates, but you could operate without them being used. There are workflows where requirement of task is not really necessary, and you might need to integrate new version of the same product from different task. This is how it is, and not sure if we can change that.
On database level, Folder is child of Project or other Folder. Task is child of Folder. Product is child of Folder. Version is child of Product, and can have reference to Task (Optional). Representation is child of Version.
From the named production tracking services, ftrack is the closest to this setup, where the task is optional too.
The database hierarchy is comming from avalon → pype → OpenPype, AYON added the reference to Task on Version, which was not possible before.
Follow up question.
I am a really big fan of the separation between tasks and products, for the reasons you explain above @iLLiCiT.
I feel tasks are a production management tool for managing artist times and tasks (duh), but once a piece of data is published, validated and integrated into the database, I don’t care as an artist downstream what task the data comes from. “Just give me latest background asset Y, or character cache X available”.
This makes it also easier to built automations, where product names/types are consistent, regardless of how different projects, supervisors, or managers wish to structure their task names.
My question though, you say there is an optional link between the version and the source task when publishing. Is that an actual link we can query with the api, or is it just implied in the productname?
Here is the flow chart that I have drawn, in case it helps someone.
I mixed database links and process flow, so it might not be 100% accurate, but it helps me keeping track of how Ayon works.
The upper part is the logic, and the lower part is an example.
I would just like to add, that product version and workfile version doesnt match most of the times (need to be forced via Ayon settings) so that connection line from top to bottom stream in the schema would be more like a dotted line aka optional one as the product version comes most of the time from the postgres DB from already existing product version (aka preceding one) for example v001 if non existing any preceding one.
Indeed, I forgot the link could be off, because here we always set this ON, in Studio Settings :
Core–>Publish Plugins–>Collect Anatomy Instance Data–>Follow Workfile Version–>Active
(without this setting there is the neverending search for what product version is related to which workfile version, it drives artists crazy)
