-
Notifications
You must be signed in to change notification settings - Fork 273
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
run pending migrations in a single transaction #243
Comments
this conflicts a bit with the transaction=false feature (at least for postgres). I think transaction=false migrations would need to error if more than one migration is pending. |
previous ticket, that I forgot about #99 |
Nontransactional migrations will require more thought - it will be common in test code to execute the entire set of migrations at once, which would preclude the strategy described above. |
dbmate cannot assume what a user wants here because there is no dependency information, and some migrations are not transactional. There could be a flag --batch-transaction to apply all in a single transaction. This will run into issues where you only want a subset in that batch. In #434 I added a flag to specify a specific transaction. This could be expanded to specify multiple specific transactions to select a subset. |
#434 supports specifying multiple migrations now, so if there was a --batch-transaction flag it would be possible to specify specific migrations to batch together. |
Currently dbmate issues one commit per pending migration. I think it should issue one commit at the end, after all migrations have been run.
Migrations are going to be run either before or after the code deploy. If run before, the old code must be compatible with both the new and old state of the database. If running after, the new code is compatible with both states.
Users of dbmate must ensure not only this, but also that the old/new code is compatible with all possible migration states between the first and last pending migration at which a failure may occur. I think this violates expectations - users may segment their migrations for various reasons like logical division or to avoid corrupting previous migrations while iterating in a dev environment. The manner in which pending migrations are split should not affect the end state of the database in case of failure.
If migrations are run in a single transaction, both options are safe:
Contrast with today:
The only "drawback" I see is it can cause expensive, successful migrations to roll back, but I think that's probably what you want in the failure situation.
The text was updated successfully, but these errors were encountered: