Skip to content

no-application-schema-check

Keep JSON shape and closed application value sets out of database CHECK constraints.

Why

A database CHECK that repeats an application-owned JSON schema or enum-like value set creates two validators that can drift and turn an otherwise valid application deployment into failed writes.

Fix

If the application owns the contract, validate the JSON payload or closed value set with the typed application boundary before changing its CHECK. Preserve database-owned validation and checks needed by other writers; use an exact SARJ118 suppression explaining ownership. Keep relational constraints such as foreign keys, uniqueness, nullability, and cross-column invariants in the database.

Examples

Before — flagged Database duplicates a JSON array schema
supabase/migrations/001_execution_plan.sql
CREATE TABLE execution_plan (
outcomes JSONB NOT NULL CHECK (
JSONB_TYPEOF(outcomes) = 'array'
AND JSONB_ARRAY_LENGTH(outcomes) BETWEEN 1 AND 10
)
);
After — preferred Application schema owns the JSON document contract
supabase/migrations/001_execution_plan.sql
CREATE TABLE execution_plan (
call_id UUID PRIMARY KEY REFERENCES
CALL (id),
outcomes JSONB NOT NULL
);
Before — flagged Database duplicates an application enum
supabase/migrations/001_call.sql
CREATE TABLE
CALL (
status TEXT NOT NULL CHECK (status IN ('queued', 'completed'))
);
After — preferred Application enum owns the closed value set
supabase/migrations/001_call.sql
CREATE TABLE
CALL (status TEXT NOT NULL);