Phinx: Add a "clean" command to remove **MISSING** migrations from the phinxlog table

[saada]

I'm proposing a "phinx clean" command that would basically find and remove all MISSING migrations from the phinxlog table. This happens when you delete a migration FILE after it was added to the database.

[joshribakoff]

I seem to run into this problem too. Problem is I added a migration with change() implemented & ran it, then immediately ran "rollback" which fails, saying it can't find the migration to rollback (which it JUST ran)

[robmorgan]

hi guys you should never delete a migration file after you run it. I would suggest you keep all files in the migrations directory for the life of your project otherwise other developers etc, can never accurately setup the project, see history/design decisions etc.

[saada]

What if you're in development mode? What if you're just trying something
out on your local machine?

On Tuesday, April 22, 2014, Rob Morgan [email protected] wrote:

hi guys you should never delete a migration file after you run it. I would
suggest you keep all files in the migrations directory for the life of your
project otherwise other developers etc, can never accurately setup the
project, see history/design decisions etc.

—
Reply to this email directly or view it on GitHubhttps://github.com/robmorgan/phinx/issues/206#issuecomment-41044444
.

Sincerely,
Mahmoud Saada

[hkdobrev]

@robmorgan There is a very valid case for that. You don't want to delete migration files, but when you switch a branch this how it all looks like. I am often removing some entries from phinxlog to be able to perform a rollback.

[saada]

@hkdobrev , that's exactly what happened to me!

[joshribakoff]

If you're doing some local development, and you decide you don't want a change before committing it, you should be able to back out of that change without pushing it publicly and having it run in production.

Almost needs some sort of "reapply" which would "rollback" and then "migrate" again, because often I am changing a migration before committing it, and manually running those two steps to "reapply".

[robmorgan]

ok guys I can see some valid points here. for those that are testing migrations, you can simply git reset right? in order to quickly test something and remove the file again?

[saada]

I think you mean git checkout. And no that won't work because in the
scenarios we're describing, you're switching between different branches
with different works in progress.

I like the idea of "reapply", but I can see a use case for "clean".
"Reapply" would simply rollback to before the missing migration and
migrates while removing any missing steps from the phinx table. "Clean"
would keep everything the same and just deletes the missing steps from the
phinx table.

I'm just brainstorming, really. Maybe "clean" is sufficient?

On Thursday, April 24, 2014, Rob Morgan [email protected] wrote:

ok guys I can see some valid points here. for those that are testing
migrations, you can simply git reset right? in order to quickly test
something and remove the file again?

—
Reply to this email directly or view it on GitHubhttps://github.com/robmorgan/phinx/issues/206#issuecomment-41258847
.

Sincerely,
Mahmoud Saada

[saada]

What about separate databases per git branch??????

On Thursday, April 24, 2014, Mahmoud Saada [email protected] wrote:

I think you mean git checkout. And no that won't work because in the
scenarios we're describing, you're switching between different branches
with different works in progress.

I like the idea of "reapply", but I can see a use case for "clean".
"Reapply" would simply rollback to before the missing migration and
migrates while removing any missing steps from the phinx table. "Clean"
would keep everything the same and just deletes the missing steps from the
phinx table.

I'm just brainstorming, really. Maybe "clean" is sufficient?

On Thursday, April 24, 2014, Rob Morgan <[email protected] wrote:

ok guys I can see some valid points here. for those that are testing
migrations, you can simply git reset right? in order to quickly test
something and remove the file again?

—
Reply to this email directly or view it on GitHubhttps://github.com/robmorgan/phinx/issues/206#issuecomment-41258847
.

Sincerely,
Mahmoud Saada

Sincerely,
Mahmoud Saada

[NeoEGM]

@saada In some cases (like mine) separate databases per git branch are not affordable since some dbs are very big (a few gigabytes at least).

[zvaehn]

this may help:

1. check your database for a table called phinxlog.
2. remove the ** MISSING ** columns.

[rquadling]

Take a look at using my breakpoint pull request (https://github.com/robmorgan/phinx/issues/494 https://github.com/robmorgan/phinx/pull/497).

My team and I use this for multi-branch development. Switching between branches requires a vendor/bin/phinx rollback -t 0 to rollback to the last breakpoint, which is set whenever master is deployed and the migrations migrated.

[joelperry93]

I've also been having troubles with switching branch to one where newer migrations do not exist. I need to rollback the migrations to the state of the branch I've switched to. Has anyone got a solution for this?

All I can think of is that it'd need to store the 'down' SQL into the migrations table every time you migrate up. That way, when the migration files disappear, we can figure out which migrations are missing (from the database table) and run the 'down' SQL in order.

My use case is that I'm switching between branches that are further along than other branches, and I'd like to rollback automatically for the branch that I've changed to.

[saada]

whatever we do, it should perhaps be designed with git hooks in mind. Things like post-checkout so that phinx can run the proper commands automagically. We'd have to do some diffing between migrations in previous branch vs current branch and then do like @joelperry93 mentioned. Rollback any missing migrations in current branch vs previous branch.