South is “a tool to provide consistent, easy-to-use and database-agnostic migrations for Django applications.” However, as South’s website says, since Django 1.7 now has its own migrations tool South has been deprecated. I personally think the new Django migrations are a little bit better.

However we still use South at FiveStars and I thought other people who still use South might appreciate these notes.

See list of migrations (asterisks means already applied)

[shell]
$ ./manage.py migrate –list [app name]
[/shell]

Apply latest migrations

[shell]
$ ./manage.py migrate [app name]
[/shell]

Fake migration

[shell]
$ ./manage.py migrate [app name] [version #] –fake
[/shell]

Migrate backwards

[shell]
$ ./manage.py migrate [app name] [version #]
[/shell]

Migrate back to zero state, i.e. nothing

[shell]
$ ./manage.py migrate [app name] zero
[/shell]

Create first migration

[shell]
$ ./manage.py schemamigration [app name] –initial
[/shell]

Create subsequent migrations

[shell]
$ ./manage.py schemamigration [app name] —-auto
[/shell]

Create empty schema migration

[shell]
$ ./manage.py schemamigration [app name] —-empty [migration name]
[/shell]

Create data migration

[shell]
$ ./manage.py datamigration [app name] [migration name]
[/shell]

Review migration history

[sql]
select * from south_migrationhistory order by applied;
[/sql]

Redo migrations that have been hand edited

Sometimes you will find someone followed the bad practice of hand editing a migration after it has been committed. For example they’ll add another column. Because you have already run the migration you may not notice this until many migrations later when something breaks because of this missing column.

To fix this:

1. Fake migration backwards to the edited migration
2. Migrate back one before the edited migration
3. Migrate forward one for the edited migration
4. Fake migrate forwards the rest until you get to your current state
5. Migrate the migration that previously was giving problems