The registry

Persisted business logic is FeatureQL in the registry. A /* SQL */ block can be used for setup and migration, and cannot be stored as a feature. A persisted feature is a function of named inputs.

Validation of every change

CREATE, REPLACE and DROP are checked for type compatibility, dependency existence and acyclicity before they take effect. A change that would structurally break a downstream feature is refused.

A unit or type change on a persisted feature re-derives every dependent in the same transaction. A conflict rolls the whole statement back.

• EXPLAIN (FIELDS (MUTATION_DRY_RUN)) reports which dependents a change would revisit and which would conflict, without writing.
• CREATE TEMPORARY FEATURES overlays a definition for one request and leaves the registry unchanged.

See Create features .

One current definition, with history

A feature is identified by its name and the hash of its dependency tree. Each name has one current definition.

The managed registry also keeps an append-only log of definitions:

• SHOW REVISIONS and DESCRIBE list the history.
• AS OF reads the definitions at a past revision of main.
• ON BRANCH tries a change as an overlay, without writing to main.

Past definitions are compiled with the current compiler. Permissions and views are not versioned. See Catalog revisions and Branch overlays .

One executable corpus

Documentation examples, conformance tests and the help corpus used by assistants are the same artifacts. They are listed by SHOW TESTS and run by the conformance runner .

Tests for your own features are separate SQLLogicTest (SLT) files that you write and run.

Limits

• The registry checks that the graph is well formed and that each change is consistent with its dependents. A replacement that passes these checks can still change a number, which is what regression tests cover.
• Approval of a change is part of your release process. See Change management .