v1.8.1

db-migrate 1.8.1: what's new since 1.0.0

1.1 to 1.8 make v2 migrations usable for data as well as schema. You get reversible data migrations, background jobs, soft deletes, releases with deprecations, and a status command. Scopes can now have a database of their own. v1 migrations keep working unchanged.

Highlights

• DML migrations (1.3): reversible data changes inside v2 migrations. Transactions run per batch, and soft delete and purge are supported (1.4). They need db-migrate-base 2.5.0 or newer.
• Background migrations (1.4, 1.6): long-running data changes run as jobs, started by db-migrate work or executeWork(). Jobs pause while migrations run, and down reverts them.
• Releases and deprecations (1.5): tables and columns can be marked as deprecated. Rows deleted in soft mode are purged with a later release.
• db-migrate status (1.7): shows what db-migrate knows about the database.
• Static seeds (1.3): data you can rerun for development and tests. These replace the seeders that were dropped in 1.0.
• Adopt existing objects (1.1): db.adopt.createTable, addColumn, addIndex, addForeignKey and the other create/add instructions declare objects without executing anything. That covers objects made by v1 migrations or by hand. After that, v2 migrations can revert them fully.
• Scopes with their own database (1.1): a scope's config.json with connection settings connects that scope on its own. Lock, recovery progress and the learned schema are kept per scope.
• v1 migrations without a transaction (1.2): exports._meta = { transactions: false }, e.g. for CREATE INDEX CONCURRENTLY.
• Defaults for environment variables in the config (1.8).
• Backups of data migrations are dropped once they are final (1.7).

⚠ Upgrade notes

• Option precedence (1.8.1): options given on the command line or to an API instance now win over rc files. rc files only replace the defaults.
• Scope state (1.1): a scope whose config.json sets a database or schema now keeps its state in that database. If its v2 migrations ran before, run db-migrate fix:<scope> once.
• Jobs of scopes with their own database (1.8.1): run them with db-migrate work:<scope> or executeWork({ scope }). work:all is refused.
• Dropping unknown objects (1.1): dropping a table, column or foreign key that db-migrate doesn't know needs { irreversible: true }. Such a migration is not rolled back, and down refuses it.
• Drivers: DML migrations need db-migrate-base ≥ 2.5.0. _meta.transactions: false with MySQL needs db-migrate-mysql ≥ 3.1.2. The pg setting schema is applied again with db-migrate-pg ≥ 1.6.1.

Bug fixes

Scopes and commands

• up:all and the other all-scope commands ran only the top-level migrations.
• sync and fix of a scope didn't find its migrations (#471).
• create:<scope> --sql-file put the SQL files into the wrong folder.
• Migrations created with --sql-file no longer print their SQL (#775, #829, #805, #422).
• db:create and db:drop resolved before they were done, and exited the process when called through the API.

Config and API

• rc aliases (state-table, migration-table) and --ignore-completed-migrations are honored again. The app's own arguments are parsed correctly in module mode.
• Calls on one API instance start from that instance's options (#474).
• Plugins are found when hoisted, and a broken plugin is skipped (#826).

v2, DML and background jobs

• changeColumn is reverted to the column's previous spec.
• fix learns the steps of releases again. It learns migration records once, from an empty schema.
• A deprecated table keeps its deprecation when it is renamed for it.
• A job runs in the scope of its migration, is not run again once its migration is recorded, and keeps its record when recovered by rollback.
• work --dry-run lists the jobs that would run.
• fix --backup-state keeps jobs and DML migration records.
• --non-transactional also turns off transactions in DML migrations.
• Soft delete: the mark is matched as a whole. On MySQL a soft delete is refused if its mark would be cut off.

Full changelog: v1.0.0...v1.8.1