Skip to content
Sarj Code Standards

no-database-triggers

Keep behavioral logic in application code, not database triggers.

SARJ114 Rule source Tests Catalog JSON

Why

Under a single-writer application architecture, triggers hide writes and state transitions from engineers reading application code and make the behavior difficult to exercise through ordinary unit-test seams. Migrations must express integrity through declarative constraints and explicit application transactions.

Fix

Use a declarative database constraint where possible or explicit transactional application behavior; migrations cannot waive the trigger ban with inline suppressions.

Examples

Before — flagged Hidden trigger behavior
supabase/migrations/001.sql
CREATE TRIGGER update_timestamp
BEFORE UPDATE ON calls
EXECUTE FUNCTION set_timestamp ();
After — preferred Declarative database invariant
supabase/migrations/001.sql
ALTER TABLE child
ADD CONSTRAINT child_tenant_fk FOREIGN KEY (organization_id, parent_id) REFERENCES parent (organization_id, id);

Formerly: no-create-trigger