Ticket #1048 (closed enhancement: wontfix)

Opened 4 years ago

Last modified 4 years ago

Version number per Model/Table not per APP

Reported by: guettli Owned by: andrew
Priority: minor Milestone: The Future
Component: migrations Version: unknown
Keywords: Cc:


If someone rewrites south (maybe for integration to django core), it would be good to have a version number of data migrations per model or table, and not for app like it is now.

This would solve many conflicts which pop up, if several people work on one application.


developer1 alters model_a: migration_model_a_1 gets created
developer2 alters model_b: migration_model_b_1 gets created.

Change History

comment:1 Changed 4 years ago by andrew

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

I'm going to reject this, with good reason.

The only problem this claims to solve is conflicts, yet they can still arise (by people working on the same model). Furthermore, it throws atomicity out of the window - if you want to have a migration that moves a column across tables, or splits a column off into a new tables, or so on, that's now not possible under this scheme sensibly.

There's better ways to achieve conflict resolution, namely a) a semi-intelligent merge method (something I've wanted to do for a while and which is technically possible with the current migration format and b) developers talking to each other about what they're doing if they both go to work on the same models of the same app. Most of the time, I find that a codebase with separate apps rarely has two people working on the same app at once.

This proposal would also slow down South by significantly increasing the size of the dependency graph, and forcing us to run more transactions and SQL statements.

Note: See TracTickets for help on using tickets.