Migration manifest

graph_to_migration_manifest converts any lineage graph into a flat, JSON-serialisable manifest — useful for planning a feature-store migration between databases or environments.

Build a manifest

from tdfs4ds.lineage import build_teradata_dependency_graph, graph_to_migration_manifest
import json

graph = build_teradata_dependency_graph(sql_query=sql)

manifest = graph_to_migration_manifest(graph)
print(json.dumps(manifest, indent=2))

Schema

{
  "views":  [{"database": "demo_user", "name": "DS_CUSTOMER", "type": "dataset"}],
  "tables": [{"database": "src_db",    "name": "TRANSACTIONS",
              "primary_index": ["TX_ID"], "partition_columns": ["TX_DATE"]}],
  "edges":  [{"from": "demo_user.DS_CUSTOMER", "to": "demo_user.FEAT_ENG_CUSTOMER"}]
}

primary_index and partition_columns come from table_info collected by the graph walker — same data you see when iterating graph['nodes'].

Scope to a single schema

manifest = graph_to_migration_manifest(graph, filter_database=tdfs4ds.SCHEMA)

When filter_database is set, any edge whose source or target falls outside the filter is dropped. The result is a self-contained manifest for migrating one logical feature store boundary at a time.

Typical migration steps

1. Build the manifest for the source environment.
2. In the target environment, create_data_domain and setup().
3. Re-create the source views in dependency order (manifest['edges'] gives you a topological hint).
4. Re-run every registered process — run(process_id) once per process in the manifest's views[*] with type == 'view'.
5. Re-build any datasets — build_dataset(...) for every type == 'dataset'.

Comparing two environments

import json

with open('manifest_dev.json')  as f: dev  = json.load(f)
with open('manifest_prod.json') as f: prod = json.load(f)

dev_views  = {(v['database'], v['name']) for v in dev['views']}
prod_views = {(v['database'], v['name']) for v in prod['views']}

print('Missing in prod:', dev_views - prod_views)
print('Missing in dev :', prod_views - dev_views)