-
Notifications
You must be signed in to change notification settings - Fork 65
Description
Introduction
Hi, i've found this package and now use in my projects, it works fine, but i see a problem with decision no down migrations.
My answer on question
If we needed to reverse something, we could just push another migration negating whatever we did that went boom ... Why roll back when you can roll forward?
is my case on the project where we have many branches in a time, and as developer i change branches pretty frequent.
When 2 branches have different migrations, i have problem when one branch apply migrations, then i checkout and server fall with error about no match signatures of migrations.
The typical solution i know is a "down migrations", then i may just roll back migrations, before checkout to another branch.
The question
How to solve the problem while development, when we have to change branches with different migrations?
Currently this problem slow down our development process. As a crude workaround we have to create DB dumps and restore DB from dumps, but it is very slow, since in development environment we need a DB with pretty close data structure to production, so even lightweight DB snapshot may takes a dozens gigabytes.
I've thoughts to create own solution (or maybe fork and upgrade your solution) to implement down migrations for development purposes. But it would take time and we would be forced to maintain our own solution. So would prefer to get known your opinion as architect of this solution, how to solve the problem for teams with development process like we have.
Again, i understand the idea about immutable migrations and i like it. We no need down migrations on production, since it's confusing and potentially dangerous for traceability and data consistency maintenance.