Opened 10 years ago

Closed 10 years ago

Last modified 5 years ago

#24535 closed New feature (wontfix)

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

Reported by: Daniel Hahler Owned by: nobody
Component: Migrations Version: 1.7
Severity: Normal Keywords:
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

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.

Change History (4)

comment:1 by Tim Graham, 10 years ago

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.

comment:2 by Tim Graham, 10 years ago

Resolution: wontfix
Status: newclosed

in reply to:  1 comment:3 by Andrew Badr, 5 years ago

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.

comment:4 by Simon Charette, 5 years ago

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.

Last edited 5 years ago by Simon Charette (previous) (diff)
Note: See TracTickets for help on using tickets.
Back to Top