Data domains¶
A data domain is a project-level namespace that isolates features and
processes inside a shared feature store. Two teams can register a feature
called total_amount for the same CUSTOMER_ID entity without colliding —
the catalog stores DATA_DOMAIN as part of every key.
The three helpers¶
Always use the dedicated functions — never assign tdfs4ds.DATA_DOMAIN
directly:
| Function | Purpose | Side effect |
|---|---|---|
tdfs4ds.create_data_domain(name) |
Create and activate a new domain. Idempotent (warns if it already exists). | Sets tdfs4ds.DATA_DOMAIN = name. |
tdfs4ds.select_data_domain(name) |
Activate an existing domain. | Sets tdfs4ds.DATA_DOMAIN; raises ValueError if the domain is unknown. |
tdfs4ds.get_data_domains() |
List every domain (the active one is marked *). |
None. |
Setup vs analytics¶
The convention used in the bundled notebooks:
| Notebook role | Function to use |
|---|---|
| Bootstrap / setup notebook | create_data_domain — first-time creation |
| Analytics / modelling notebook | select_data_domain — activate the existing one |
select_data_domain raises rather than silently creating a typo'd domain.
Cross-domain features¶
Every public query (catalog reads, build_dataset, the consumer agent) is
scoped to the active domain. To pull features from two domains in the same
dataset, build two datasets and join the views manually — build_dataset
does not accept multiple domains by design.
Storage layout¶
Every domain shares the same physical catalog tables (FS_FEATURE_CATALOG,
FS_PROCESS_CATALOG, …) — the DATA_DOMAIN column inside each table is the
isolation key.