Search code examples
pythondjangodatabase-migrationdjango-southmerge-conflict-resolution

Why does south use migration files?

I'm working on a Django app with one other developer. I love Django so far.

But I picked up a copy of south in order to be able to modify models.py during development, and now we're having migration merge conflicts all the time.

Yup, I already got the memo:

The important message here is that South is no substitute for team coordination - in fact, most 
of the features are there purely to warn you that you haven’t coordinated, and the simple merging 
on offer is only there for the easy cases. Make sure your team know who is working on what, so they 
don’t write migrations that affect the same parts of the DB at the same time.

But I am confused as to why migration files exist at all? If models.py is the authoritative word on db schema, what do migration files give me? Hopefully this will help me understand how to use south better.

Solution

  • If you don't care about your data, then you don't need migration files, nor even South FWIW - you could just wipe out your tables and re-run a manage.py syncdb. The point here is to allow for data migrations too, which has proven to be a very useful feature once you're in production and have a lot of real data you care about.

    Suppose you have a field you want to split in two or move to another model etc... If you don't want to loose your data, you need a three-steps process:

    1. add the new field(s)
    2. move your data to the new field(s)
    3. remove the old field.

    This translates into

    1. a first schema migration
    2. a data migration
    3. a second schemamigration

    NB : you can of course put it all into a single migration file (and it's obviously the cleanest solution since it makes your migration atomic), but it's easier to use the automatic schema migration generation for 1. and 3.

    To make a long story short: "migration files" are actually migration scripts, which is what you'd need to write for any real-life production project. South mainly provides a supporting framework (migration scripts can be really tricky) and a very handy schema migrations generator that makes your life easier for one of the most common use case (non-destructive schema changes).