trackteroid

Trackteroid

---

Emballage déclaratif et orienté objet pour les requêtes ftrack. Interactions de style fonctionnel puissantes avec les collections résultantes.

Trackteroid dépend de Ftrack et de son API Python, un logiciel de gestion de projet et de suivi de la production spécialement conçu pour l'industrie des médias et du divertissement. Il est couramment utilisé dans les domaines du film, de la télévision, de l'animation, des effets visuels et des jeux.

Installation

Installer et mettre à jour à l'aide de PIP:

pip install trackteroid

Motivation

Nous avons décidé de construire une API d'emballage autour de l'API Ftrack Python pour relever plusieurs limitations et défis qui surviennent lorsqu'ils interagissent directement avec l'API Python. Bien que l'API Ftrack Python offre beaucoup de flexibilité, certains aspects peuvent rendre le développement et la maintenance plus encombrants et moins intuitifs. En créant une API d'emballage, nous visons à surmonter ces défis et à fournir une expérience plus rationalisée et conviviale. Voici les principales raisons de cette décision:

• Simplification de la requête

  • L'un des principaux défis de l'API Ftrack Python est la nécessité d'écrire des requêtes sous forme de chaînes de type SQL à l'aide d'un langage de requête personnalisé. Cette approche conduit souvent à une mise en forme complexe des chaînes et peut être difficile à lire, à comprendre et à déboguer. Ce projet vise à simplifier la logique de requête et fournit une interface de requête plus expressive et intuitive. Cela permet aux développeurs de construire des requêtes en utilisant une syntaxe plus naturelle et lisible, entraînant une amélioration de la productivité et une réduction des erreurs.

• Optimisation des performances de requête

  • Lorsque vous travaillez avec l'API Ftrack Python, les développeurs doivent s'assurer qu'ils rédigent des requêtes efficaces pour minimiser les appels de base de données inutiles et optimiser les performances. Cela nécessite un examen attentif de la logique de récupération des données et une compréhension des implications de performance des différentes constructions de requête. En revanche, notre API fait un effort supplémentaire en essayant d'optimiser automatiquement les requêtes des performances. En tirant parti de diverses techniques d'optimisation, nous visons à réduire le nombre de requêtes de base de données, à optimiser la récupération des données et à améliorer les performances globales du système. Cela atténue le fardeau des développeurs à optimiser manuellement leurs requêtes, leur permettant de se concentrer davantage sur les fonctionnalités et les fonctionnalités de la construction.

• Abstraction de la complexité du schéma de base de données

  • La construction de requêtes avec l'API Ftrack Python nécessite une bonne compréhension du schéma et des relations de la base de données sous-jacents. Cela peut être un obstacle pour les développeurs qui ne connaissent pas les subtilités du modèle de données Ftrack. Nous visons à résumer les complexités du schéma de la base de données et à fournir une interface de niveau supérieur qui protège les développeurs des détails. Cela simplifie le processus de développement et permet aux développeurs de se concentrer sur les fonctionnalités qu'ils souhaitent construire, plutôt que de se perdre dans les subtilités de la structure de la base de données.

• Amélioration des collections résultant

  • Les collections renvoyées par l'API Ftrack Python après l'exécution des requêtes peuvent ne pas toujours être suffisamment pratiques pour interagir directement. Ils peuvent manquer de certaines méthodes ou propriétés qui rendraient la manipulation et le traitement des données plus efficaces. Nous pouvons enrichir les collections résultantes avec des fonctionnalités supplémentaires et des méthodes d'utilité adaptées aux besoins spécifiques de notre application. Cela améliore l'expérience du développeur en fournissant des moyens plus pratiques et intuitifs de travailler avec les données récupérées, améliorant finalement la productivité et la maintenabilité du code.

• Amélioration de l'accessibilité sur le terrain

  • L'API Ftrack Python ne présente pas toujours les champs disponibles directement sur les entités, obligeant les développeurs à se référer à la documentation ou à inspecter le schéma pour déterminer les propriétés disponibles. Nous prenons des mesures pour améliorer l'accessibilité sur le terrain dans une certaine mesure. Nous visons à fournir un moyen plus intuitif et découvrable pour les développeurs d'accéder aux champs d'entités en les exposant directement via l'API. Cela permet aux développeurs de temps et d'efforts en éliminant la nécessité de référencer constant de la documentation ou de l'inspection du schéma sous-jacent. Il améliore la productivité et la maintenabilité du code en rendant les champs d'entités plus accessibles et découvrables dans le flux de travail de développement.

En résumé, trackeroid essaie d'autonomiser les développeurs en fournissant un moyen plus intuitif et efficace d'interagir avec la plate-forme FTRACK, accélérant finalement le développement, l'amélioration de la qualité du code et l'amélioration de l'expérience utilisateur globale.

Comparaison

Avec trackteroid ...

 # Calculate and display the total time duration logged for 
# AssetBuild types within specified Shots and Folders.
#
# output:
# Found 9 assetbuilds.
# Found 1 assetbuilds with timelogs.
# {16.0: ['Drone Craft'],
#  'No time tracked yet.': ['Drawer Cabinet 01',
#                           'Gothic Commode 01',
#                           'Shelf 01',
#                           'Side Table 01',
#                           'Small Wooden Table 01',
#                           'Vintage Wooden Drawer 01',
#                           'Wooden Table 01',
#                           'Wooden Table 02']}
  
from pprint import pprint

from trackteroid import (
    Query ,
    AssetBuild ,
    Folder ,
    Task ,
    Project
)

assetbuild_collection = Query ( AssetBuild ).
    by_name ( Project , "sync" , "showroom" ).
    by_name ( Folder , "Asset%" , "Delivery 3" ).
    get_all (
        projections = [
            Task . Timelog ,
            Task . Timelog . duration
        ]
    )

print (
    f"Found { len ( assetbuild_collection ) } assets. n "
    f"Found { assetbuild_collection . count ( lambda ac : ac . Task . Timelog ) } assetbuilds with timelogs."
)

pprint (
    assetbuild_collection . group_and_map (
        lambda abc : abc . Task . Timelog . fold (
            0 ,
            lambda current , tc : current + tc . duration [ 0 ] / 3600
        ) or "No time tracked yet." ,
        lambda abc : abc . sort (
            lambda abc : abc . name
        ). name
    )
)

... contrairement à l' API Ftrack Python .

 # Calculate and display the total time duration logged for 
# AssetBuild types within specified Shots and Folders.
#
# output:
# Found 9 assetbuilds.
# Found 1 assetbuilds with timelogs.
# {16.0: ['Drone Craft'],
#  'No time tracked yet.': ['Drawer Cabinet 01',
#                           'Gothic Commode 01',
#                           'Shelf 01',
#                           'Side Table 01',
#                           'Small Wooden Table 01',
#                           'Vintage Wooden Drawer 01',
#                           'Wooden Table 01',
#                           'Wooden Table 02']}

from pprint import pprint

import ftrack_api

session = ftrack_api . Session ( auto_connect_event_hub = False , auto_populate = False )
project_names = ( "sync" , "showroom" )
folder_specific = "Delivery 3"
folder_unspecific = "Asset%"

query = (
    f"select id, name, assets.name, parent.name, project.name, "
    f"assets.versions.task.timelogs, assets.versions.task.timelogs.duration "
    f"from AssetBuild where project has (name in { project_names } ) "
    f"and parent[Folder] has (name is ' { folder_specific } ' or name like ' { folder_unspecific } ')"
)

assetbuilds_no_duration = [ "No time tracked yet." , []]
assetbuilds_timelog_duration = [ 0 , []]

assetbuilds = session . query ( query ). all ()

for assetbuild in assetbuilds :
    has_duration = False
    for asset in assetbuild [ "assets" ]:
        for version in asset [ "versions" ]:
            durations = [ _ [ "duration" ] for _ in version [ "task" ][ "timelogs" ]]
            if any ( durations ):
                for duration in durations :
                    assetbuilds_timelog_duration [ 0 ] += duration / 3600
                if not has_duration :
                    has_duration = True

    if has_duration :
        assetbuilds_timelog_duration [ 1 ]. append ( assetbuild [ "name" ])
    else :
        assetbuilds_no_duration [ 1 ]. append ( assetbuild [ "name" ])

print (
    f"Found { len ( assetbuilds ) } assetbuilds. n "
    f"Found { len ( assetbuilds_timelog_duration [ 1 ]) } assetbuilds with timelogs."
)

assetbuilds_no_duration [ 1 ]. sort ()
assetbuilds_timelog_duration [ 1 ]. sort ()

pprint (
    dict (
        [ assetbuilds_no_duration , assetbuilds_timelog_duration ]
    )
)

Usage

Voir la dernière documentation pour les détails d'utilisation.