Login Database Migrations And Schema Contracts
Purpose
Login-server migrations own the shared Postgres schema used by login, game runtime, account admin, social state, persistence retry, command audit, farming state, and encounter memory. The schema contract sidecar tells gates and game-server readiness which tables, indexes, columns, and migration anchors must exist.
Migration Ownership
The login server embeds migrations with the SQLx migrator and applies them during startup bootstrap. Game server code reads the resulting schema but does not own migration application. That split keeps schema changes centralized while allowing game-server readiness to reject drift.
SQL File Rules
Migration files use ordered NNNN_description.sql names. Keep numbering contiguous, avoid duplicate ids, use lower-snake identifiers, prefix indexes with idx_, and add safe defaults when introducing NOT NULL columns to existing tables.
Schema Contract Sidecar
schema_contracts.json records a schema version plus required indexes, required not-null columns, and anchors. Anchors are named runtime expectations that protect important SQL fragments from being changed without an intentional contract update.
Gate Behavior
The migration gate checks numbering, SQLx loadability, identifier shape, structural snapshots, required anchors, the schema sidecar, and the login-server migrator path. This catches common drift before a service boots against a partial schema.
Adding A Migration
- Add the SQL migration.
- Update
schema_contracts.jsonwhen runtime code relies on a new table, index, column, default, or anchor. - Update game-server readiness constants when the game server must refuse startup without the migration.
- Run
cargo run -p xtask --features sqlx-migrations -- login-server-migrations.
Failure Modes
Missing anchors usually mean runtime-sensitive SQL changed without a contract update. Nullable required columns, unsafe ALTER TABLE, SQLx parsing failures, and wrong migrator paths mean the service may not be able to initialize safely.