Constraints: revisit CHECK only if a write bypasses BerlinDB (expression-layer, not Kern)

[JJJ]

Background

From the #232 layering discussion (Kern = declared nouns). Today the constraint surface is split: Index covers UNIQUE KEY, Relationship covers FOREIGN KEY, and a standalone CHECK constraint is not modeled at all. A unified Constraint object (or a broadened story across Index/Relationship) would let a developer declare table constraints uniformly - which puts it on the Kern axis.

Sketch (not committing to a shape)

• A declared constraint carrying a kind (CHECK / UNIQUE / FOREIGN KEY), its columns/expression, and a name, that emits its DDL fragment - much like Index::get_create_string() / Relationship::get_create_string().
• Decide the boundary: does this replace the UNIQUE-via-Index and FK-via-Relationship paths, or only add CHECK alongside them? (Likely add CHECK; keep Index / Relationship as-is to avoid churn - reconcile in design.)
• Cross-engine caveat (Audit: cross-engine SQL compatibility (MySQL/MariaDB dialect assumptions across generated SQL) #220): CHECK enforcement differs (older MySQL parsed-but-ignored it; MariaDB and MySQL 8.0.16+ enforce; SQLite supports it) - validate before relying, do not assume.

Status

YAGNI until a feature needs CHECK; filed to capture the axis + the current split. Related: #232, #220, and the FK work in #205 / #193.

[JJJ]

Decision (2026-07-12): revisit only if needed; NOT a Kern class

Discussed and de-scoped. Two conclusions:

1. CHECK is not Kern-worthy - it's expression syntax, not a declared schema noun. A View (Kern: model a database VIEW as a first-class (declared) object #235) is something a developer authors (a definition with a lifecycle) -> Kern. A CHECK's body is a boolean predicate (price >= 0) - the same thing BerlinDB already builds for WHERE via Clauses\Predicate + comparison operators. It merely appears in CREATE TABLE; it belongs to the Clauses/Operators build axis, not Kern. So if ever built, it reuses the expression machinery rather than becoming a Constraint Kern class.

2. It's largely redundant and non-portable. BerlinDB already enforces value integrity in PHP via Column::validate_* callbacks - on every engine and version, with real error messages. WordPress core uses zero CHECK constraints, and MySQL silently ignored CHECK before 8.0.16 (2019), so a relied-upon CHECK is a portability footgun. UNIQUE is already Index; FK is already Relationship. The only thing CHECK adds over the PHP validators is catching writes that bypass BerlinDB entirely (raw SQL / another app on the same table) - real but rare, and the reason WP itself skips it.

Kept open, parked: revisit only if a concrete need to guard against out-of-BerlinDB writes appears. No Constraint Kern class.