Why does schemamigration --auto creates a spurious migration?

Question

I'm developing a Django app and I came across with a weird issue concerning 2 south's migrations made in parallel.

One migration corresponds to the creation of a new model (let's call it '0001_add_model'), and the second one corresponds to the addition of a field to an existing model (let's call it '0001_add_new_field_to_model'). Now, this 2 migrations were made in parallel in 2 different branches (an error I won't make again). When I ran ./manage.py migrate, south told me that there was a problem, and that I could run the command with --merge to run the migrations anyway. Given the fact that the 2 actions concern different models, I though there shouldn't be a problem to do so, so I did it and everything went right.

The problem emerged when I did a ./manage.py schemamigration --auto from that point it generated me a migration practically identical to 'add_model' except for the field added in 'add_field_to_model'. It looks like this:

( * ) 0001_auto__add_model

( * ) 0001_auto__add_new_field_to_model

-> ( ) 0002_auto__add_model

If I do it the other way around then it generates the reverse, ie, a migration to add the field that was added in 'add_field_to_model'. In both cases, the new migration generated is clearly inapplicable because those changes already exist in the database.

What puzzles me is why it generates such migration. How does south's autodetector works in order to create new migrations?

What I did in order to continue developing is to run this spurious migration with --fake, but I think the ultimate solution will be to reset migration history since that point, which is cumbersome, as it is replicated in several environments.

Answer 1

The problem comes from the "frozen" model states not being consistent between your first two migrations. If you look at your migration files, you'll see that the Migration class has a models attributes which is the "frozen" representation of the models at the moment the migration was generated. South then uses this representation - the one in the last applied migration file - to detect changes and generate a new migration. Since your two "0001_XXX" migrations have diverging "frozen" models, any new migration will be generated against a wrong representation of the models.

The solution is, obviously, to fix your "0001_XXX" migration's models manually.

And, yes, South + parallel branches can be a kind of a pain, but I fail to see how South could do a better job ATM anyway.