Wrap the migration execution in a transaction if supported by the adapter. This will require a method in the adapter like hasTransactions
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.
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.
ActiveRecord Ref: https://github.com/rails/rails/blob/master/activerecord/lib/active_record/migration.rb#L744
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 ;-)
Despite that I'm using MySQL, which doesn't support transactions for DDL, transactional migrations is a great feature, so - another push from me :)
Good article here: http://adam.heroku.com/past/2008/9/3/ddl_transactions/
This feature will really benefit Postgres when we develop an adapter for it.
#6 adding transaction support. migrations now run inside transactions…
… if the adapter supports it
@pcoroli No worries!
Would this be very similar if not identical to how Laravel is providing transactional migrations?
Here's a link
I would greatly disagree that each migration should be completely independent and isolated from one another.
Here some examples:
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
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
all migrations are now run inside a single transaction