search

cakephp / phinx

PHP Database Migrations for Everyone
https://phinx.org
MIT License
4.47k stars 890 forks source link

Please improve migrate command to work same as rollback when target is set to an old migration ID #1118

Open heskyji opened 7 years ago

heskyji commented 7 years ago

Currently migrate command does not respect version_order:execution config or breakpoints like rollback command does.

I have a CD environment for our main codebase. I'm using phinx in a separate codebase to manage its database. I'm using the version_order:execution config. For each CI build that triggered by a code merge, I store the Migration ID in the artifact. Then during deployment, I want to run migrate -t {Migration ID} together with the main artifact deployment. Please note this need to support rolling back the entire system to an old artifact.

Right now, when if I run migrate -t {Migration ID}, where {Migration ID} is in the past when I do a system roll back, phinx will rollback all the migrations that are created after that {Migration ID} and disregard any existing breakpoint. I think this is wrong, it should detect the {Migration ID} is in the past then perform same behaviour as rollback -t {Migration ID}, which respect the version_order:execution config and any breakpoint.

For the CD environment I described above, this is very important because I can then have a consistent method to handle database migrations for my deployments, doesn't matter if it is a new release or a rollback.

My workaround right now is that in the deployment process, I have to check if the {Migration ID} is up or down. If it is down, I call phinx migrate -t {Migration ID}; if it is up, I will have to call phinx rollback -t {Migration ID}.

Thanks.

rquadling commented 7 years ago

OOI, could you not just use rollback?

heskyji commented 7 years ago

@rquadling Yes I could. That would be my workaround for now.

Since migrate command does not only support migrating forward, but also supports migrating to a Migration ID in the past; then users would expect it behaves the same as rollback when it tries to migrate backwards, which need to respects the version_order:execution setting and any breakpoints.

In my case, it is important to have one consistent way to migrate to any point (i.e. a given Migration ID) that is associated to a release artifact. That point might be the latest migration, and might be anywhere in the execution history.

Hope that makes sense. Thanks.

rquadling commented 7 years ago

I can certainly see the issue you are having.

My concern is how to deal with migrating to a point in the past that still has unmigrated migrations.

If the migration target is in the past, it may well be easiest internally if we first call 'rollback' and then 'migrate' command to the same target.

For the time being, maybe a simple shell script that does both of these commands.

heskyji commented 7 years ago

It is still migrating forward when migrating to a point in the past that still has unmigrated migrations. So I guess phinx would apply the oldest unmigrated migration first. That shouldn't be a problem.

dereuromark commented 6 years ago

Is this still an issue?

heskyji commented 6 years ago

@dereuromark I actually haven't been using it since August. So I couldn't validate it at this point. Unless an improvement has been merged in, I assume it is still an issue.