South incorrectly orders primary_key alterations in backwards()

[anonymous]

I was moving from using a OneToOneField? as a primary key to having an auto-managed primary key. South generated code in backwards() that added the old OneToOneField? primary_key before removing the new auto-managed id field, causing an error on running that complained about having multiple primary keys.

Versions:
python 2.6
django 1.2.3
south 0.7.2
MySQL 5.1

Steps to reproduce:
Create a model with a OneToOneField? as its primary key and migrate to this state.
Delete the OneToOneField?, migrate forwards.
Migrate backwards, an error occurs.

[anonymous]

I'm discovering more now (this is the first time I've gone backwards with south so a lot of bugs are cropping up).

Namely, when you add a table with a unique constraint across multiple fields, the table deletion statement in backwards() occurs before the unique constraint deletion, like below:

        # Deleting model 'Team'
        db.delete_table('registration_team')

        # Removing unique constraint on 'Team', fields ['registrant', 'registrant_team_number']
        db.delete_unique('registration_team', ['registrant_id', 'registrant_team_number'])

This throws an error for me. The delete_unique should either be scrapped, or even better appear before the table deletion.

I am realizing that maybe these bugs are all just symptoms of MySQL's inability to modify schemas within transactions, but they can be cleaned up by south in valid ways.

[ogier]

So I ended up making the changes necessary to support this myself, and put the patch on an older ticket that had the same problem: #434.

[andrew]

I'm going to close this as a duplicate of #434, since it now seems redundant; I'll go over that and check it in if it's good after DjangoCon?.