Validation

Built-in data validation — no external tools required

OndatraSQL validates data as part of execution — not as a separate step. No external tools. No test framework. No extra runs.

Every model can enforce:

Constraints → block bad data before it’s written
Audits → detect regressions after materialization
Warnings → monitor without failing

-- @constraint: user_id NOT NULL
-- @constraint: email EMAIL
-- @audit: row_count > 0
-- @audit: row_count_change < 20%
-- @warning: null_count(email) < 5%

This ensures no invalid rows enter the table, no empty datasets are produced, sudden data drops fail the run, and minor issues are logged without blocking.

When to Use What

Type	When it runs	On failure	Use for
Constraint	Before insert	Nothing written	Enforce correctness
Audit	After insert	Rolled back	Detect anomalies
Warning	After insert	Logged only	Monitor trends

Mental Model

Validation happens in two stages:

Before data is written → validate individual rows. NULL checks, uniqueness, ranges, formats. If a constraint fails, nothing is committed.

After data is written → validate the result. Row count changes, distribution shifts, historical comparisons, cross-table reconciliation. These need the committed data and DuckLake snapshots.

Warnings use the same patterns as audits but only log — they never block.

Automatic Rollback

If an audit fails, the transaction is rolled back via DuckLake time-travel. No bad data is committed. Your data remains consistent — automatically.

Built on DuckLake

Audits can use time-travel to compare against previous versions:

-- This happens automatically inside audit patterns
SELECT COUNT(*) FROM table AT (VERSION => prev_snapshot)

This enables regression detection, historical comparisons, and reproducible validation — without external tooling.

Usage

Define rules as directives in any model:

-- @constraint: id PRIMARY KEY
-- @audit: row_count > 0
-- @warning: row_count_change < 50%

See Constraints, Audits, and Warnings for all available patterns.