Documentation
¶
Index ¶
Constants ¶
This section is empty.
Variables ¶
var ErrSchemaOutdated = errors.New("approval schema is outdated")
ErrSchemaOutdated means the approval tables exist but lack a structure the module's correctness depends on. It is fatal at start-up by design: the missing structure cannot be repaired forward (the migration is CREATE TABLE IF NOT EXISTS and never alters an existing table), and running on top of it corrupts data silently rather than loudly.
var Module = fx.Module( "vef:approval:migration", fx.Invoke(registerMigration), )
Module provides automatic database migration for the approval module.
Functions ¶
func Migrate ¶
Migrate runs the approval module's DDL migration for the given database kind. Obsolete tables from earlier revisions are dropped before the schema probe so upgrades stay clean.
The migration is forward-only: each script is a set of CREATE TABLE IF NOT EXISTS statements guarded by a presence probe (needsMigration), so it provisions missing tables on a fresh or partially-migrated database but never alters an existing table. In-place column changes — an added column, a type/constraint change, or a dropped column — therefore take effect only on a freshly created database; an existing deployment that must adopt them has to be recreated. This is a hard requirement, not graceful degradation: once the code writes or reads an added column, an un-recreated older database errors on that column. The approval module is pre-1.0 and assumes recreation over in-place schema evolution; table removals are the one exception, handled explicitly through dropObsoleteTables.
func Verify ¶ added in v0.42.0
Verify asserts the approval tables carry the structure the module's write paths assume. It runs on every boot — including when auto-migration is on, because CREATE TABLE IF NOT EXISTS silently accepts a pre-existing table of any shape, so provisioning proves nothing about a table someone else created.
The check that matters is the primary key. Approval's writes are compare-and-set statements whose correctness rests on a row being uniquely addressable: engine.ConcludeActiveNodeVisit requires its UPDATE to touch exactly one row and fails the transaction otherwise, and the task/instance transitions treat "zero rows affected" as a lost race. Against a table with no primary key — the shape a dump restored without constraints produces, and which then admits duplicate ids — those statements match a duplicate set instead, so approvals roll back or silently double-apply. Failing the boot turns that into one clear error instead of an intermittent engine bug.
Types ¶
This section is empty.
Source Files