Wrap migration execution in a transaction #6

robmorgan opened this Issue Dec 28, 2011 · 11 comments


None yet
5 participants

robmorgan commented Dec 28, 2011

Wrap the migration execution in a transaction if supported by the adapter. This will require a method in the adapter like hasTransactions

pcoroli commented Nov 1, 2012

Hi Rob, has there been any traction on that since the issue has been opened?

It would be great to have transaction both on a single transaction level, and on a whole batch. To give an example - say there are 5 migration scripts in general, 2 of which have already been applied to the DB. On the following migrate run command the system would have to apply the remaining 3 migrations. In case of a failure of at least one of those migrations, let's say the one under number 4, the system should have rollback transaction for migration number 4, and 3.



robmorgan commented Nov 1, 2012

Hi @pcoroli,

No not really. I do plan to implement this feature soon but really I'm waiting until users push for it.

I can tell you how it would operate though - it would only be on a single transaction level. This is because migrations are supposed to be completely independent and isolated from one another. You will find other migration systems work this way.

After we implement this feature if you wanted migration 4 to rollback 3 (if it fails), I would suggest you combine them both into the same migration file.



pcoroli commented Nov 2, 2012

Thanks for a quick reply, @robmorgan.

Transaction per migration sounds good - I do agree that having migrations isolated is the way to go.

Consider my interest in this feature as a push ;-)


zuker commented Nov 2, 2012

Despite that I'm using MySQL, which doesn't support transactions for DDL, transactional migrations is a great feature, so - another push from me :)


robmorgan commented Nov 4, 2012

This feature will really benefit Postgres when we develop an adapter for it.

@robmorgan robmorgan added a commit that referenced this issue Nov 4, 2012

@robmorgan robmorgan #6 adding transaction support. migrations now run inside transactions…
… if the adapter supports it

robmorgan closed this Nov 4, 2012

pcoroli commented Nov 5, 2012

Thanks, @robmorgan


robmorgan commented Nov 5, 2012

@pcoroli No worries!

Would this be very similar if not identical to how Laravel is providing transactional migrations?
Here's a link

zetrax commented Dec 15, 2014

I would greatly disagree that each migration should be completely independent and isolated from one another.

Here some examples:
example 1:
Migration 1 adds a new table and gets committed
later an error is found for migration 1, since altering already applied migration files is not supported a new one needs to be created to fix the error in migration 1.
Migration 2: fixes error in migration 1

example 2:
During deployment process of a new release, some migration fails. Since the newly released code assume all migration applied successfully, you end up in a difficult situation where neither your old release and new release fits the database schema. Here a desirable feature would be that the database was not altered at all and the deployment process can fall back to the old release code.

You can argue that neither examples is desirable and should be avoided through tests. But in reality you would like to safeguard against this.

I think its easy to imagine some examples where applying migrations in different order will give you different results.
migration 1: reset all bank account to 0
migration 2: add 100 bonus coins to each account

@schlndh schlndh added a commit to Maternia/phinx that referenced this issue Aug 19, 2015

@schlndh schlndh all migrations are now run inside a single transaction 63748ce
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment