Simon Frei
4459438245
Just to be entirely sure that if the migration succeeds the schema version is always also updated. Currently if a migration succeeds but a later migration doesn't, the changes of the migration apply but the version stays - if the migration is breaking/non-idempotent, it will fail when it tries to rerun it next time (otherwise it's just a pointless re-execution). Unfortunately with the current `db.runScripts` it wasn't that easy to do, so I had to do quite a bit of refactoring. I am also ensuring the right order of transactions now, though I assume that was already the case lexicographically - can't hurt to be safe.
10 lines
438 B
Markdown
10 lines
438 B
Markdown
These SQL scripts are embedded in the binary.
|
|
|
|
Scripts in `schema/` are run at every startup, in alphanumerical order.
|
|
|
|
Scripts in `migrations/` are run when a migration is needed; they must begin
|
|
with a number that equals the schema version that results from that
|
|
migration. Only one script per schema version must exist.
|
|
Migrations are not run on initial database creation, so the scripts in `schema/`
|
|
should create the latest version.
|