RFC : Ability to temporarily block migrations.

[rquadling]

Hi.

You are developing away, creating migrations, testing migrating and rolling back and forth and all is working well.

You rollback a few to do some amendments to a now unmigrated migration (imagine you are working on a branch with other developers and, as yet, the migrations haven't taken place on the production DB, so any currently outstanding migrations can be edited before the branch is closed and committed to production).

But suddenly you realise you've gone back too far. And the particular migration that is happily being rolledback is that big one which does a LOT of data manipulation.

Well there goes the next hour waiting for the rollback to finish, just to migrate forward 1 step again.

It would be nice to add a breakpoint to which rollback will automatically stop whilst there is a breakpoint present.

So, I propose a new command ...

phinx breakpoint [-t|--target="..."]

If there is no target then the most recent migration will be assumed.

If a target is supplied and it exists, it will have the breakpoint set/unset, depending upon if the migration is already set to be the breakpoint.

The breakpoint will be stored in the phinxlog table (breakpoint bit not null default 0).

During migration or rollback if the migration has the breakpoint bit set, then migrate/rollback stops.

Theoretically, you could set a breakpoint on a unmigrated migration, this would stop the migration at that point, allowing you to rollback/forward between a set of migrations. May not be too useful, but would be a supported "feature".

One use case for us would be that when we are feature branching, we don't want to be able to play with the existing committed/deployed migrations and we haven't yet flushed them and rebuilt are base schema (we have our own way of doing this, but we are happily waiting for phinx to be able to do this!).

So, upon creating a new feature branch, we would phinx breakpoint and our new feature related migrations would be the only ones we could play with, no matter how far back we accidentally attempt to rollback.

I'd appreciate any comments/suggestions/alternative implementations/etc. on this.

Happy to do the work once some feedback is given to see if this is a useful feature as well as any ideas/use cases that I've not considered.

Regards,

Richard.

[rquadling]

No feedback? Is anyone out there?

[pedanticantic]

This is a really great feature, as it stops accidental rollback of the entire set of database changes. It's really nice to have a safety net like this.

[rquadling]

Merged.