Ticket #926 (closed enhancement: wontfix)

Opened 4 years ago

Last modified 4 years ago

Option to use timestamp migrations rather than serial number

Reported by: msabramo@… Owned by: andrew
Priority: minor Milestone:
Component: commands Version: unknown
Keywords: timestamp Cc: msabramo@…


The serial numbers work great most of the time, but we recently ran into a fair amount of trouble when multiple developers were changing (different) models in a project on different branches. Because each developer is on a branch and doesn't see the migrations that developers on other branches are generating, it is extremely easy for the serial numbers to collide and then it's a mess to sort through after merging.

Timestamped migrations don't completely eliminate the problems with working on multiple branches -- differing frozen ORM state is also a problem, but they at least make it easier to see what happened and to sort through the migrations a bit more easily.

Since this is a huge change in how South works, I would implement this as an option that defaults to False.

Change History

comment:2 Changed 4 years ago by anonymous

Here's what it looks like in action:

$ ./manage.py schemamigration publisher --auto
 + Added field foobar on publisher.Tag
Created 2011-09-28T05:52Z_marcabramowitz.py. 
You can now apply this migration with: ./manage.py migrate publisher

comment:3 Changed 4 years ago by msabramo@…

Here is why Rails switched from serial numbers to time stamps:


comment:4 Changed 4 years ago by andrew

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

I've WONTFIXed this before, and I'm afraid I'm going to have to do so again.

Firstly, South does not identify migrations by the number; in fact, it does nothing special, and just ASCII-sorts them (so, as you know, switching to dates is easy, and you can do it manually if you want to). That means that, even if two migrations have the same number, there is still a fixed, implicit ordering - unlike Rails, where they (I believe) just used the number, and so it went all wibbly.

Adding dates does not prevent clashes; it merely moves that clash somewhere else. If I add a migration and someone else does at roughly the same time, after a merge we're still going to have a hole in our migration history.

(Unlike Rails, South won't just run missed in-the-middle migrations, you need to pass --merge)

Additionally, using dates presents further potential problems; I know many machines that do not have a correct UTC clock setting (be they sharing with Windows and not set up right, drifted non-NTP machines, or VMs that have no RTC).

Basically, I see no concrete improvement that adding dates brings, and I see one concrete downside - harder-to-type migration names.

Note: See TracTickets for help on using tickets.