07 · Tables A→ZE · Govern with column domains
What a domain is
Domains restrict which values a column accepts - fixed, hierarchical, or reference - enforced on every write.
A domain restricts which values a column will accept. It goes beyond a data
type ("any string") to "one of these values", and it's enforced on every
insert_rows and
merge_rows - bad data never lands. Domains are
stored as metadata on the Delta table, so the rules travel with the data.
Three kinds
| Type | Restricts a column to… | Use for |
|---|---|---|
| Fixed (enum) | a finite value list | status codes, country codes, any closed set |
| Hierarchical | values that depend on a parent column's value | category → subcategory, country → region |
| Reference | values present in another table's column | cross-table referential integrity (like a foreign key) |
This is Eddytor's headline governance feature - hierarchies to enforce rules.
How they behave
- Enforced on write - an insert/merge with a disallowed value is rejected.
- Case-sensitive -
"Active"and"active"are different values. - Live (reference domains) - validated against the source table at write time; deleting a source value can orphan dependents.
The workflow
- Profile first -
profile_tableto understand cardinality. A string column with fewer than 20 distinct values in 10k+ rows is a good candidate (infer_schemaalso flags these). - Set the domain -
set_column_domain. - Validate -
validate_domain_valuesto catch existing mismatches (with typo suggestions).
Good to know
Set domains before importing data. Rejecting bad
values at write time is far cheaper than cleaning them up afterward.