Track database migrations in a table with dated .sql files #51
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "claude/database-migrations-review-28cbe5"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Summary
Moves the SQLite migration runner from an inline array +
PRAGMA user_versionto timestamped.sqlfiles tracked in a_migrationstable.apps/app/src/server/migrations/asYYYYMMDDTHHMMSSZ_name.sql, bundled withimport.meta.glob. Filenames are validated at load._migrationsrecords name, SHA-256 andapplied_at, so applied migrations are queryable. Startup fails if an applied file was edited, if the database has a migration this build doesn't know, or if no migrations are found.BEGIN IMMEDIATEtransaction (no lock table needed; SQLite's write lock plusbusy_timeoutserialises concurrent starts). A read-only up-to-date check skips the lock when nothing is pending.PRAGMA user_versionget the matching files recorded as applied (without re-running) via a fixedlegacyVersionslist.user_versionis left untouched.getDb()now caches the handle only after migration succeeds (before, a failed migration left an unmigrated handle cached).busy_timeoutis set beforejournal_mode, andforeign_keysis on.Testing
tsc --noEmitpasses.db.tsthrough Vite against a fresh database and a legacyuser_version = 2database with existing data: both end with both migrations recorded, existing rows are kept, and reopening applies nothing.Notes