Store migrations in the database, for independent rollback

[AxelTerizaki]

I'm submitting a...

• Bug report
• Feature request
• Question

Hello.

I've ran into a little problem while developing my app which relies on db-migrate for migrations.

I currently have a master branch with my app's current DB structure, and have started developing a new feature which requires a migration file. I created it along with the down migration, and started doing dev. A user told me about a bug with the current branch, so I switched back to it. However, I couldn't start my app since it relies still on the "feature" migration I did earlier. I tried a db-migrate down but then it couldn't find the migration file, which is normal since it's on the feature branch, not on the current one. I thus had to checkout my feature branch again, apply the down migration, and re checkout my current branch.

I believe there could be an easy way to fix this kind of behavior :

• I run db-migrate sync all and unless I'm mistaken, I think it should check if a migration with the same name still exists on the filesystem and "down" it if it doesn't anymore (thus allowing switching from branch to branch on a project to be much easier.)

• I looked at the migrations table and it only stores a filename for the migration. Since the filename may not exist anymore when switching branches, I believe one fix for this would be to store the contents of the up and down migration files in database, thus allowing db-migrate to retrieve the queries to run if the file doesn't exist anymore.

That would be a nice feature addition, I believe :)

Thanks for your hard work, db-migrate is a really helpful tool.

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[AxelTerizaki]

Hum, does this mean the issue will never be looked at?

[wzrdtales]

I run db-migrate sync all and unless I'm mistaken, I think it should check if a migration with the same name still exists on the filesystem and "down" it if it doesn't anymore (thus allowing switching from branch to branch on a project to be much easier.)

This is a false assumption. It is impossible to "down" a migration that does not exist anymore, since this needs the logic of the migration itself. Sync is a target based migration. This means you give it a parameter, like a timestamp and may be in the future semver versions and it will execute everything until this point no matter if that is down or up.

[AxelTerizaki]

I used the sqlite package before and their take on it is that the migration SQL is stored in database, so if for one reason or another the file does not exist anymore (in the example I explained, a branch change, or a rollback) the SQL to downgrade the migration can still be executed since it can still be fetched from the DB

[wzrdtales]

That would be an extra feature to consider, but that would introduce a new command since it would break the behavior of sync.

I can see the benefit of this, however this would need to reconsider looking at "old" migrations to fetch migrations not yet executed. I will look for a methodology that will not break the current behavior here, probably a flag for the commands to rescan.

[AxelTerizaki]

Thank you for considering this feature :)