Make "manage.py migrate" atomic, i.e. rolling back any migrations on failure

[Daniel Hahler]

While each migration by itself appears to be atomic, the whole "manage.py migrate" process isn't.

I think that it would be useful to wrap it into a transaction altogether.

This would rollback all successful migrations in case a later one fails, and would help with deployment, where you want to have all or none of the migrations being applied.

[Tim Graham]

I'm not sure it's feasible. For example, in PostgreSQL you cannot update a table (data migration) and then alter the table schema in one transaction.

[Andrew Badr]

Replying to Tim Graham:

I'm not sure it's feasible. For example, in PostgreSQL you cannot update a table (data migration) and then alter the table schema in one transaction.

That's not true (anymore?). I just tried it in a local shell and it worked. Maybe there are certain sequences of alter/updates that don't work. Haven't been able to find docs spelling it out.

[Simon Charette]

Even if this limitation is now lifted it would still be impossible in the case of non-atomic migrations/operations ​either explicit or implicit because the database backend doesn't support transactional DDL. The framework also defers quite of bit of operations (search for usage of deferred_sql in the code base) and some are ​simply unsupported in a transaction.

If you really want to give this a go you can easily override the migrate command by wrapping it's handle in an atomic block for the specified --database but you have to keep in mind that'll likely break under certain circumstances and it has the potential to take your side database down if the transaction is held because of a long running operation.

If you really want to roll back on failure you can easily emulate such thing by keeping track of where you are before performing the migration and migrating to the previous state if any exception is raised. This is something you can easily achieve with the commands the migration framework currently exposes.