feature: implement DevMigrator closes #283#394
Conversation
Up to standards ✅🟢 Issues
|
| Metric | Results |
|---|---|
| Complexity | 117 |
| Duplication | 0 |
NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.
…tion # Conflicts: # src/Cli/ExecuteCommand.php
|
This latest change adds per-statement progress tracking, to allow for partial migration success. @pixeldrift64 and I are working together on a busy production app, and the database struggled to add a new column in amongst heavy user traffic, but half of the migration did succeed. This change accommodates for this, so a partial success will be recorded, and the next migration will resume from where the current migration succeeded. Integrity checks are still applied for the whole files, so if a partially applied migration is edited before it resumes, it will correctly fail with a migration integrity error instead of continuing with changed SQL. Both _migration and _migration_dev tables are upgraded automatically to add the new progress column when migrations run, so existing production installations can adopt the featire without a manual schema change. Feedback is welcome while I give this more thought. |
# Conflicts: # src/Cli/ExecuteCommand.php # src/Migration/Migrator.php # test/phpunit/Cli/ExecuteCommandTest.php
1 participant
New features:
gt migrate --devruns normal migrations, then appliesquery/_migration/devfiles tracked separately in the_migration_devtable.gt migrate --dev-mergeruns normal migrations, then renumbers and moves applied dev migrations into the canonical migration directory and records them as already applied in_migration.Key changes are in the new
DevMigrator,MigratorandExecuteCommand. I've split out the Migrator class into an abstract base class so both Migrator and DevMigrator can share the functionality.