• Understand mechanics of South and gain exposure to some non-trivial scenarios
• Improve confidence of use
• Know how to undo or avoid messes
• Cover ways to work with South rather than against it
• Evaluate the relative strengths and weaknesses of South as a tool

A pretty basic execution model. This is what we want.

2 operating principles:

• Determining what to apply when a migration is run
• Determining what has changed when a schemamigration is created

Migration state is determined by two factors:

• Presence of a migrations directory
• south_migrationhistory

User Interface to South is pretty simple overall and can be fudged.

Convert an App to South

Predict what will happen

Convert an App to South

Verify

• migrations dir added to app
• migration file created
• entry added to south table

Manage new apps with South

schemamigration

datamigration

http://south.aeracode.org/docs/tutorial/part3.html

Always have a recovery strategy.

When feasible, backup your DB before running migration operations

Try with a backup DB

Use an alternate settings

Support for non-native Model fields

South can't make assumptions about how Fields in the wild operate

http://south.aeracode.org/docs/customfields.html

Trying to use Model methods at migration time

Forgetting to use South ORM

MySQL transaction failure

Operations appear to hang

Needing dependencies

Break changes down into finest grained steps possible

Export data if needed to handle multiple steps

• Change a field in a base class
• Changing model inheritance

...there are many possibilities where the South model could break down, so learn to live with it.

Communication is good

Updating with converted apps

Conflicting migrations

Dealing with 3rd party migrations

Migrations can be disabled

Setting: SOUTH_MIGRATION_MODULES

http://south.aeracode.org/docs/settings.html#south-migration-modules http://lincolnloop.com/blog/2011/jul/18/disabling-south-migrations/

Resetting Migrations

http://lincolnloop.com/blog/2011/jun/20/resetting-your-south-migrations/

Maintaining migration history

Comparison to nashvegas

• South getting rusty?
• Documentation weaknesses
• Andrew amenable to moving to github?

• Mailing list
  • Search the mailing list to see what others have encountered.
• IRC
• Tutorials
• LL Blogs

• Complex changes may require non-ideal solutions
• Maintaining migration history can be expensive and little used.
• South is best used as a team coordination tool, not an enforcer of data history and schema integrity.

Andrew Godwin

volunteers

• Shawn Milo
• martinm
• Carl Meyer