SQL migrations #
Add files named 0001_description.sql, 0002_description.sql, and so on.
Umzug records their filenames in the strict schema_migrations table.
0001_ingestion_index.sql defines the account, run, scenario, and Jetstream
cursor tables. Later migrations add the independent discovery cursor and
bootstrap phases (0003_collection_bootstrap.sql), then author status-check
timestamps (0004_author_status_refresh.sql), and anonymous leaderboard
identities and submissions (0005_leaderboards.sql). Add future changes as
new numbered files.
0007_scenario_discovery_order.sql adds an index for public scenario discovery,
ordered by publication time and URI. Publication times are compared as instants
so timestamps with different UTC offsets sort chronologically.
0008_player_listing_order.sql adds author-specific chronological indexes for
player scenario and run pages. It replaces the older scenario author/date index
with one that compares timestamps as instants.
0009_guest_run_subdivision.sql sets subdivision to 5 on older Guest run
snapshots that lack the field. It checks their historical board fingerprint
before updating, preserves explicit subdivisions and stored challenge identities,
and keeps snapshot JSON in the canonical order used by current writers. An
unexpected fingerprint aborts the migration transaction without changing records.
The full Node application's startup applies pending files before opening the
HTTP listener. All pending SQL and migration bookkeeping share one
BEGIN IMMEDIATE transaction. A failed migration prevents startup and rolls
back the batch; migrations do not run during build or prerender.
- Append migrations; never rename, remove, or edit an applied file.
- Use
STRICTtables, explicitNOT NULL, and domainCHECKconstraints. - Use bound parameters in application queries. Migration SQL is trusted code.
- Do not put transaction statements or connection pragmas in migration files.
- Migrations run forwards. Back up before upgrading; rollback means restoring both the previous image and its database backup.
- Stop the running service before deploying schema changes. The migration lock serializes concurrent migration commands, but does not make old application code compatible with a new schema.
The runner rejects missing or out-of-order migration history, including starting an older image against a database with newer migrations.