Description
Tooling to help migrate config values when schema changes.
Specific scenario: schema version drift
When a tenant's schema version is upgraded via UpdateTenant, the server invalidates the validator cache (internal/schema/service.go:660-662) but does not re-validate existing config data against the new schema's constraints.
If a schema update adds a required field, tightens a constraint (e.g. min: 0 → min: 10), or removes a field, existing values that violate the new rules persist in the database. No error surfaces until someone attempts a new write that triggers validation.
This means the system can be in a state where stored config is technically invalid according to the active schema version.
Possible approaches
- Background worker: optionally re-validate a tenant's config when their schema version is bumped
- Migration CLI command:
decree migrate --tenant <id> --dry-run to detect and report drift
- On-read validation: flag stale values when they're read (non-blocking)
Migrated from zeevdr/decree#40
Description
Tooling to help migrate config values when schema changes.
Specific scenario: schema version drift
When a tenant's schema version is upgraded via
UpdateTenant, the server invalidates the validator cache (internal/schema/service.go:660-662) but does not re-validate existing config data against the new schema's constraints.If a schema update adds a required field, tightens a constraint (e.g.
min: 0→min: 10), or removes a field, existing values that violate the new rules persist in the database. No error surfaces until someone attempts a new write that triggers validation.This means the system can be in a state where stored config is technically invalid according to the active schema version.
Possible approaches
decree migrate --tenant <id> --dry-runto detect and report driftMigrated from zeevdr/decree#40