-
-
Notifications
You must be signed in to change notification settings - Fork 528
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
Migrations should happen in a transaction #1364
Comments
This comment was marked as outdated.
This comment was marked as outdated.
@Stale This is one of the top 5% of requested features by upvotes - I don't think it should be closed. |
@rjmunro - I happened upon your issue whilst scanning for transaction-related issues (anything that might explain why I'm seeing sporadic transaction-related failure under load ... in my case it seems as if a given transaction option is being ignored) ... Regarding MySQL, it does not support transactions for DDL queries at all (maybe the latest version does, or some flavour like MariaDB, but not the version I'm using at). This means automatic transaction support in the sequelize migration tool will not help you (in the case of MySQL). Having run into pretty much the same problem as you I can up with a couple of pragmatic rules regarding development of migration files:
you end up with potentially a lot of migration files but it's also bullet-proof in terms of rollback. you could argue that you need to have multiple queries per migration file in order to keep deployments in sync with migrations (i.e. that every release has just one migration). I believe that that is almost impossible to police when there are multiple features being developed by multiple developers, especially when you throw CI & automation in the mix, not to mention that it is likely that most deployments do not have a corresponding migration. Actually from a rollback POV the 'sequelize-meta' table should be storing batch-numbers along side the migrations that represent which migrations were run for any given |
This comment was marked as outdated.
This comment was marked as outdated.
@iamjochem This is good advice for people stuck on MySQL or it's forks. For users of virtually any other databases, transactions are supported for DDL statements, and we should use them. Transactions even reduce downtime because while all the DDL is going on in the transaction, the old data can still be read and updated. Splitting migrations into one query each doesn't help you if you make a mistake and the query fails. A transaction will just put the database back to exactly how it was before you started. |
@rjmunro - forcing migrations to contain only one query mimics transactions ... because the migration becomes all-or-nothing, failure results in a determinate state for the DB and the migrations (if a migration with multiple queries, that does not use a transaction, fails then you are stuck having to manually fix the DB because you can no longer perform an |
From a cursory look at the sequelize codebase and some following experiments, the following works for in Postgres.
I haven't taken a complete look at all the Can any of the maintainers (@sushantdhiman ?) confirm whether this is behavior that we can rely on to remain consistent (and potentially documented)? |
Any thing that touches But its not a correct solution as operation on sequelize_meta wont be covered with this transaction |
Thank you for the quick response and for confirming! Makes sense how it is not a complete solution. I took a deeper look at how it might be possible to share this transaction with the migrator, and I think I have an inkling why this issue is still open :) Off the top of my head, maybe one way to support this is to modify the cli here (https://github.com/sequelize/cli/blob/master/src/core/migrator.js#L49) to add a 3rd parameter with an unmanaged transaction that the E.g.
Some care will need to be done to make sure the transaction is eventually closed or rolled back. If you think this is worth exploring I'd be happy to tinker with it if I have time or to contribute a bounty for this. Lastly - I wanted to thank you for maintaining Sequelize! At minimum I would be happy to help write docs to clarify the behavior RE: the options parameter you mentioned in your comment. |
Sounds good |
Sequalize migrations and seeders are one big deception. It should not even be released without transactions. How can seeders be useful without it? |
This caught me off guard. |
I think sequelize community really deserves to have this feature |
I had assumed that sequelize was correctly supporting transactions with mysql in successful migrations. Should not sequelize, at least, warn about transactions not being made? |
Idk about that, I only discovered it via this issue, reading https://sequelize.org/master/manual/migrations.html or https://sequelize.org/master/class/lib/query-interface.js~QueryInterface.html section didn't help, nobody on my team of 12 new about this as well. That this can be applied to I also assumed, as well as my team, that migrations are by default run in transactions 🤷♂ |
Is it correctly understood that MySQL dialect atm does not support transactions in migrations? |
@aat2703 Every dialect supports transactions in migrations. The only matter here is that they are not set by default. |
@papb - MySQL does not allow you to run multiple DDL statements in a single transaction - each DDL statement implicitly commits/rollsback any active transaction - which is why I suggested the 1 query per migration strategy for MySQL users. |
@iamjochem Ouch, I didn't know that, and apparently that is true for most dialects (not only MySQL). Postgres seems to be the only exception... But then it is no longer a Sequelize problem :) |
In the context of a migration ran against MySQL I was renaming a column and then adding another. up: function (queryInterface, Sequelize) {
return queryInterface.renameColumn('TABLE', 'COLUMNA', 'COLUMNB')
.then(() => queryInterface.addColumn('TABLE', 'COLUMNA', Sequelize.STRING))
} That failed throwing
The migration was partially applied and I had to fix it manually as previously explained by @iamjochem But if I wrap it up inside a transaction manually up: function (queryInterface, Sequelize) {
return queryInterface.sequelize.transaction( t => {
return queryInterface.renameColumn('TABLE', 'COLUMNA', 'COLUMNB', {transaction: t})
.then(() => queryInterface.addColumn('TABLE', 'COLUMNA', Sequelize.STRING, {transaction: t}))
});
} It works as expected I'd like if you please can explain why it DOES work. I've read in this thread that MySQL does not support DDL transactions. What I've learned from this experience is that any migration that has more than one call to the query interface should perform its work under a manually created transaction. Maybe the docs should make that point clearer if the library cannot do it automatically behind the scenes Looking forward to your opinions, thanks in advance and take care of the coronavirus. |
I really would like to have a global transaction... |
I'm confused, do transactions in migration files not work in these conditions? Ubuntu 20.04 I tried creating a similar migration as shown on the docs.
Running the migration throws an error (which is what I need for this test).
But what is relevant here is that Can we get some clarification on where this is supposed to be working? |
That's because MySQL actually does support mixing modifying the database structure inside migrations (if I recall correctly it automatically commits the transaction before modifying the table). The code in the example only works correctly with databases that support it like PostgreSQL (on databases that doesn't you end up with the transaction being ignored). |
Can you tell me what "mixing modifying the database structure" means? Sorry English is not my native language and I think I'm just not understanding your comment right.
Ah, thank you. My confusion stemmed from one of the earlier comments where they claimed it worked on MySQL. |
@jvasseur So is this only an issue when using transactions during migrations on MySQL databases? I'm currently using sequelize with a MySQL database and transactions work in regular queries from my API backend. Do transactions just not work within the context of doing a migration? |
It's not the context of migrations, but |
I've recently noticed that migrations that partially fail actually commit the partially successful parts of the migration, leading to broken databases. I've been working with Sequelize for quite a while and I'm pretty sure this didn't use to be the case. What I would expect is that if I catch an error in promise chain of a migration and throw it, the entire migration transaction would be rolled back. I would not expect to have to manually specify a transaction. That is not the case (anymore). What is the best way to get this behavior (back)? And isn't this simply a bug? |
Migrations have never run in a transaction as far as I know |
@mschipperheyn - are you by any chance using a database other than Postgres? It seems PostgreSQL is the only database server that we have confirmed has full support for running DDL statements (i.e. |
IMHO It is not sequelize job to fix that. Just keep DML and DDL migrations in separate files. We do that and works fine, you can even configure a linter or some tooling to enforce the rule |
This is intentionally a reopening of sequelize/sequelize#1882 which was closed automatically by a bot. I think it's a fundamental feature for a migration engine.
What you are doing?
There was a problem applying a migration, due to a issue in the code of the migrations.
What do you expect to happen?
I expect the whole migration to be rolled back.
Nearly all database engines support DDL in transactions. It should be the default way updates are done, unless the user chooses not to.
Even if the database does not fully support transactions for DDL (MySQL) sometimes migrations can make updates to data e.g. adding records to lookup tables, and it should be the default to roll these back.
What is actually happening?
The database ends up in an inconsistent state, with half the changes of the migration applied, but not the other half. I can't re-run the migration, I can't easily go back. I have to manually finish the migration and then manually update the meta tables.
The text was updated successfully, but these errors were encountered: