Ticket #342 (closed enhancement: wontfix)

Opened 6 years ago

Last modified 6 years ago

Ability to consolidate multiple migrations on the same app to run as one SQL ALTER statement

Reported by: adam@… Owned by: andrew
Priority: minor Milestone:
Component: migrations Version: 0.6.2
Keywords: Cc:


Introduce a flag, or change the default, to allow multiple migrations on the same app to be consolidated so they run as one SQL statement. This will greatly decrease the migration time for production rollouts involving multiple migrations on large tables without having to manually consolidate them during the QA process.

Change History

comment:1 Changed 6 years ago by andrew

  • Status changed from new to closed
  • Resolution set to wontfix

I'm afraid this isn't technically possible; South migrations cannot be translated directly into SQL, as some commands (e.g. delete_unique) first run a query on the table to determine the constraint name.

While for some databases it is, in theory at least, possible to write one big query to drop the constraints, in some others it's not, and the additional code complexity from something like that is not something I want in South at the moment.

The only way to get SQL for a migration on a given database is to first run a migration on a copy of the database and then use the same queries again on the live one. You can make South show the queries it runs using --verbosity=2 if you want to use this method.

Also, if going to just a normal SQL file was bad enough, going from that to one ALTER statement is very database-specific (some databases don't let you put more than one operation in per statement).

Basically, I'm going to have to WONTFIX this, on grounds of technical infeasibility. I understand the need to have quick deployment of database changes in production, but given there's other options (replay the SQL made against a copy of the database, have a pair of DBs you upgrade one after the other, or if you're using Postgres, the highest transaction serialisability level will let you push most basic changes while the server is running) I'm not sure I can justify it at all, especially when I'm pushing for a release.

Note: See TracTickets for help on using tickets.