Executing "older" migrations

[luca-rath]

If there exists a migration, that has not been executed yet, with a timestamp older than the last executed migration in the project, that migration will show with status n/a when executing bin/console phpcr:migrations:status, but running bin/console phpcr:migrations:migrate will never execute that migration. You would have to downgrade all newer migrations, then upgrade that specific migration and finally upgrade all newer migrations again. This usually happens, when you upgrade a bundle which has new migrations.

Doctrine-Migrations handles this by just executing all the non-executed migrations in the order of their timestamp, no matter if there are newer migrations that have already been executed.

[luca-rath]

Not sure if this issue belongs here or in the PHPCR Migrations Bundle

[dbu]

afaik the logic for migrations is here and not in the bundle, so the issue seems in the right place.

@dantleech built the migrations tool, lets see if he has some input on this?

[dantleech]

I guess it would be fine to copy the behavior of the Doctrine bundle here, but also sounds like a potential issue.

If that migration were executed it could invalidate all subsequent migrations? Could the solution rather be to delete it and create a new migration?

[luca-rath]

Deleting such a migration is not possible, if it lives inside a bundle you don't have control over. As a quick fix, you can of course just ignore that migration and duplicate it in your project and just adjust the timestamp, because the original migration won't be executed anyways.

Another solution would be, to just add the possibility for executing a single migration (like the bin/console doctrine:migrations:execute command). In this case, such a migration would still never be executed automatically, if there are newer migrations already executed, so you're in full control.

[dbu]

i do like the idea of a command to execute a single migration, that seems a useful functionality.

i think i would also attempt to run all missing migrations like doctrine does. with doctrine, there is the same potential problem with deletions, if migrations are not seen strictly in order, but i would expect migrations to usually add things. or remove something that will not later be added to again.