Tk-multi-loader2: "Hierarchy" mode of loading entities

Pipeline Integrations
,
1

Hi all,

Though it has been available for long, I just found that the in the setting of tk-multi-loader2, the entities field supports “Hierarchy” mode apart from the traditional “Query” mode. Here is the default values of entities field:

entities:
    default_value:
        - caption: Project
          type: Hierarchy
          root: "{context.project}"
          publish_filters: []

        - caption: My Tasks
          type: Query
          entity_type: Task
          publish_filters: []
          filters:
          - [task_assignees, is, "{context.user}"]
          - ["project", "is", "{context.project}"]
          hierarchy: [entity, content]

What’s the difference between “Hierarchy” mode and “Query” mode? Do they serve the same / different objectives? Any difference in terms of performance? I can’t find detailed explanation in its document.

Thanks!

Daniel

2 Likes
2

Hi @danielwong,

Hierarchy is only for the ui display category. Shouldn’t hit performance. for example, hierarchy: [sg_sequence, code] will display like.
Shotgun__Loader

I didn’t find query option in tk-multi-loader2. Is it old one or just for querying data? It is different than Hierarchy.

I would keep this open when experts are online.

Cheers

Loney

2 Likes
3

Hi Loney,

Thanks for your reply. What I’m asking is the entities field, whereas “Hierarchy” is one of the acceptable option in the entities.type file. Here is a complete setting of tk-multi-loader2:

  tk-multi-workfiles2:
    allow_task_creation: true
    file_extensions: []
    hook_copy_file: '{config}/copy_file.py'
    hook_filter_publishes: default
    hook_filter_work_files: default
    hook_scene_operation: '{config}/scene_operation_tk-maya.py'
    launch_at_startup: true
    location:
      version: v0.12.2
      type: app_store
      name: tk-multi-workfiles2
    saveas_default_name: ''
    saveas_prefer_version_up: true
    entities:
    - caption: Project
      type: Hierarchy
      root: "{context.project}"
      publish_filters: []
    - caption: My Tasks
      type: Query
      entity_type: Task
      publish_filters: []
      filters:
      - [task_assignees, is, "{context.user}"]
      - ["project", "is", "{context.project}"]
      hierarchy: [entity, content]
    show_my_tasks: false
    template_publish: maya_asset_publish
    template_publish_area: asset_publish_area_maya
    template_work: maya_asset_work
    template_work_area: asset_work_area_maya
    version_compare_ignore_fields: []

In the above settings, entities field has 2 entries. The “Project” entry uses “Hierarchy” mode, and the “My Tasks” entry uses “Query” mode.

I don’t know what’s the difference between these 2 modes. Do they serve different objective? And any performance difference between the two?

Thanks!

Daniel

2 Likes
7

Hi @danielwong,

The two modes do serve different functions. The main difference is that the Hierarchy type can show multiple entity types under the root whereas the Query type is restricted to a specific entity type. So if you use the Hierarchy type as shown in the info.yml, you would get a top level item for your project, then under that you would have both assets and shots.

hierarchy

This is not possible with the Query type. Your query must specify an entity_type which can be either Asset or Shot so you’d have to have two separate tabs to show both.

There are also other differences. With the Hierarchy mode you cannot specify filters or dictate the hierarchy of the tree view as you can with the Query type. When using the Hierarchy type the tree view’s structure uses the entity hierarchy from your Shotgun site. Also, the only supported root value for the Hierarchy type is {context.project} at the moment.

So basically, if you want a single tab to show all the assets and shots that belong to a project, you should use the Hierarchy type. Otherwise the Query type is the way to go.

I hope that helps clarify the differences.

Ehsan

4 Likes
8

One more thing @danielwong,

I looked into this a bit more and found a couple of known issues with the Hierarchy setup that you should be aware of.

It works as expected when your entity’s hierarchy has exactly two levels (like sequence > shot) but it breaks if you use a hierarchy with more or less levels (for example if you use sequence > type > shot). We have internal tickets on the issues, but for now if you’re using the Hierarchy method make sure your entities have exactly 2 levels.

3 Likes