Session
Trackeroid’s Session extends the functionality of the regular Session in the Ftrack Python API by incorporating additional features while preserving all the existing capabilities.
Deferred Operations
Operations can be tracked and serialized to a .dbm file using the deferred_operations contextmanager. These serialized operations can then be committed at a later time, even in a different process.
Process 1:
from trackteroid import (
Query,
SESSION,
Asset,
AssetVersion,
Component,
ComponentLocation
)
operations_file = "/tmp/recorded_operations.dbm"
with SESSION.deferred_operations(operations_file):
asset_collection = Query(Asset).by_name("bc0040_comp").get_one(
projections=[
AssetVersion,
AssetVersion.Task,
Component,
ComponentLocation.resource_identifier,
]
)
assetversion_collection = asset_collection.AssetVersion.create(
task=asset_collection.AssetVersion.Task
)
component_collection = assetversion_collection.Component.create(
name="main"
)
componentlocation_collection = component_collection.ComponentLocation.create(
resource_identifier="/path/to/final/file"
)
assetversion_collection.is_published = True
Attention
To commit previously stored operations you need to reconnect the session and commit. This is a single step to ensure no unwanted operations can be committed to the server.
Process 2:
from trackteroid import SESSION
operations_file = "/tmp/recorded_operations.dbm"
SESSION.reconnect_and_commit(operations_file)
Reusing Query Results
In certain scenarios where you repeatedly execute the same query, you can utilize the reusing_query_results context manager if the data you are querying is expected to remain unchanged. This context manager enables the retrieval of previously obtained results, executing the query only if no results have been retrieved before.
import logging
import sys
from trackteroid import (
Query,
AssetVersion,
Project,
SESSION
)
logging.basicConfig(level=logging.INFO, stream=sys.stdout)
with SESSION.reusing_query_results():
# will perform a query and logs:
# INFO:trackteroid.query:Performing query: "select id, asset.name, version from AssetVersion"
all_assetversions = Query(AssetVersion).get_all()
# will not perform the query again - nothing will be logged
all_assetversions_again = Query(AssetVersion).get_all()
print(
f"result contains same entities: {all_assetversions == all_assetversions_again}\n",
f"result is same collection: {all_assetversions is all_assetversions_again}"
)
# output:
# result contains same entities: True
# result is same collection: True
# as the resolved query will be different this will not be picked from the cache
# although the result would contain the same entities as before
# will perform a query and logs:
# INFO:trackteroid.query:Performing query: "select id, asset.name, version from AssetVersion where (version like "%")"
all_assetversions_once_more = Query(AssetVersion).by_version("%").get_all()
print(
f"result contains same entities: {all_assetversions == all_assetversions_once_more}\n",
f"result is same collection: {all_assetversions is all_assetversions_once_more}"
)
# output:
# result contains same entities: True
# result is same collection: False
Multiple Sessions
Trackteroid utilizes a single session instance called the SESSION Singleton, which serves as the default session for performing queries. If required, additional sessions can be initialized and passed to queries for performing further operations.
Default Query construction:
from trackteroid import (
AssetVersion,
Query,
SCHEMA,
SESSION,
)
# same as Query(AssetVersion)
Query(AssetVersion, session=SESSION, schema=SCHEMA.default)
Query construction with different session:
from trackteroid import (
Query,
AssetVersion,
SCHEMA
)
from trackteroid.session import Session
session = Session()
Query(AssetVersion, session=session)
Important
Although it is feasible to work with multiple sessions, there are limitations associated with it.
Since session objects serve as the foundation for collection containers and manage caches and operations, using collections from different sessions may not work seamlessly. In such cases, attempting operations across collections from different sessions will result in an EntityCollectionOperationError being raised to prevent unauthorized actions.