When a rule belongs in the database and when in the application #39

New Issue

2026-09-21T07:18:12Z

cgalo5758 commented

2026-09-21 07:18:12 +00:00

The question

Some load-bearing rules are enforced by the schema: check constraints, partial unique indexes, conferral that can only read through its own view. Others, no less load-bearing, live only in the application: the publication gating on the catalog queries, the neutrality of a product's display category, the composite gate that decides whether a product can be bought. Which layer a new rule has landed in is whatever the work that introduced it reached for. There is no stated rule for choosing.

What depends on the answer

Where the next invariant is written, and whether the split the model cards now tag per invariant is deliberate or an accident that the tags merely record.

Options known so far

Axes worth weighing rather than finished positions: whether every surface has to obey the rule or only one; whether a violation corrupts data or only misleads a page; the cost of a migration against the cost of a code change; and which layer the rule can be tested in. A convention could also say that a rule enforced in the application is written down as such, so the absence of a constraint reads as a decision.

Decided when

A developer document states the convention, the model catalog points at it, and the invariants already tagged in the model cards have been checked against it.

Migrated from status/issues.md at b7a0e15

## The question Some load-bearing rules are enforced by the schema: check constraints, partial unique indexes, conferral that can only read through its own view. Others, no less load-bearing, live only in the application: the publication gating on the catalog queries, the neutrality of a product's display category, the composite gate that decides whether a product can be bought. Which layer a new rule has landed in is whatever the work that introduced it reached for. There is no stated rule for choosing. ## What depends on the answer Where the next invariant is written, and whether the split the model cards now tag per invariant is deliberate or an accident that the tags merely record. ## Options known so far Axes worth weighing rather than finished positions: whether every surface has to obey the rule or only one; whether a violation corrupts data or only misleads a page; the cost of a migration against the cost of a code change; and which layer the rule can be tested in. A convention could also say that a rule enforced in the application is written down as such, so the absence of a constraint reads as a decision. ## Decided when A developer document states the convention, the model catalog points at it, and the invariants already tagged in the model cards have been checked against it. Migrated from status/issues.md at b7a0e15

cgalo5758 added the

kind

design

area/ops area/meta labels 2026-09-21 07:18:12 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: wiki-cafe/member-console#39