-
Notifications
You must be signed in to change notification settings - Fork 276
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Behavior when unknown migration #43
Comments
Definitely option 1. If there is any issue whatsoever, don't try to forge on--maintain data integrity and make it the user's fault if something goes wrong. If a database is at an unknown migration, that means the client is probably outdated. |
I tend to agree here with @20zinnm: you don't want to silently cover up things that go wrong. They'll come back to bite you later on when they're much harder to diagnose. |
Resurrecting a slightly older issue here but I have the same problem as described by @ericklaus-wf . In particular, when the last applied migration in the database is "unknown" then the tool would not apply any new migrations and happily tell you everything is alright. You would be non the wiser if you do not check with Think I would be able to implement option 1 described here. My proposal is this: whenever an "unknown" migration is found, then |
As discussed in GitHub issue rubenv#43 the PlanMigration function would not allow running migrations when the there are already applied migrations in the database which are not part of the migration source. In such cases the user have to decide what to do. This also fixes a bug where running the `up` migration would result in success exit status while nothing has been done.
Done, I've created a pull request which implements option 1. I think it worked out great. |
Fix is merged thanks to @ironsmile! |
Hi all, First of all, thank you for the tool. Its alleviating the anxiety I typically experience with migrations 💯 I've encountered the issue above and it seems the resolution to option 1 was to return an error however there does not seem to be a force flag available as was suggested? Here's my situation, maybe someone can offer 2c on an alternative solution: My use case is that we are splitting up our Go codebase into modular, re-usable services. Eventually they will be deployed separately, however in the mean time we are currently still merging them into one monolithic binary. Here's a simplified version of our codebase: Service B depends on Service A. I wrote an inhouse migration tool which uses packr to embed the migrations of each service and then perform them in sequence. Eventually this will not be required since Service A's deployment will be independent of Service B, but for the time being they are performed on the same DB. ServiceB's migrations succeed however when it comes to serviceA's migrations I am on the receiving end of the Thanks for your time, any tips appreciated! |
Hi @simonamdev, my use case is the same as your use case. Have you had any tips yet? |
After reading the source code, I found that we could use the different migration table name for each service instead of using the default one |
sql-migrate behaves badly when the database has migrations "unknown" to the current run of sql-migrate. This is most likely to happen when a diverged branch applied its migrations to a database while another branch also applied its own migrations to a database.
For example:
See existing issue: #37
How should sql-migrate behave when asked to perform a migration against a database that has unknown migrations? I can think of two reasonable behaviors:
(For option 2, we could also allow migrating down by adding a migrate_down column to the migrations table and storing the SQL at migrate up time. That doesn't help any existing installations, but would be a way forward.)
Which behavior seems best? I'm in favor of 2, but see the merits of 1.
The text was updated successfully, but these errors were encountered: