ALTER TABLE ADD CONSTRAINT `name` CHECK: `check` is a where filter every row must match,

ALTER TABLE ADD CONSTRAINT name CHECK: check is a where filter every row must match, e.g. {"value": {"gte": 1, "lte": 5}}. A condition on a column the row leaves empty passes, like SQL; inside or / and / not an empty value is tested as it is ({"exists": true} there fails). A key may follow a link column to the row it names, as in queries: {"parent.kind": "project"} (further dots follow further links). An empty link passes at the top level and fails inside or / and / not; only the first link of a longer path is skipped when empty (parent.parent.kind fails for a row whose parent has no parent). A link to a row that does not exist fails; on a list of links every linked row must match. not turns that into a pass: {"not": {"parent.kind": "area"}} passes a link to a missing row, so add "parent.kind": {"exists": true} to require a real one. Links resolve as in the vault (by path, from the row's note: same-named rows in two folders stay apart); renaming or moving a linked row keeps them (they follow it). Refused while existing rows violate it (they are listed); then enforced on every write, by the same rule. A write that changes a linked row re-checks the rows that link to it and is refused, listing them, when it breaks them, naming the changed row (in a batch, re-link them first: each step is checked on the vault the earlier ones left); the inverse links a write adds, undo_migration and restore_table are checked too. rename_column / rename_value follow into CHECKs; drop_column of a column a CHECK reads is refused. hint: what to do when a row breaks the rule, in your words; a refused write puts it first in its hint, and each violation of the CHECK carries it.

The schema changes only through operations like this one: never edit metastore.yaml by hand (no validation, no undo).