Last modified 6 years ago Last modified on 08/29/09 13:45:30

South 0.6

This is the 0.6 release of South, which is mostly full of architectural changes and fixes for a few bad design decisions. Nevertheless, there are also a few end-user changes.

You might also want to Download South 0.6.

Major changes in this release:

  • Introspection of models is now the default behaviour, falling back to parsing for unknown custom fields. This allows South to work with dynamically-created models. Please see the information on dynamic custom fields if your project uses custom fields.
  • South commands should now run perceivably faster on large projects, mostly thanks to some great patches and ideas from Juan and Simon at Akoha.
  • The verbosity of South commands has changed to omit printing the SQL it runs by default; you can re-enable it by passing --verbosity=2.
  • There is a new convert_to_south command, for one-shot conversion of a pre-existing application to use South.
  • Fields are now stored in a full path format, rather than as they are imported in; this should allow for better future-proofing.

Minor changes include:

  • Full compatibility with Django 1.1, including unmanaged and proxy models
  • The start of better SQLite support, including rename_column
  • Improved PyODBC support
  • A new --stdout option to startmigration, to allow migration files to be previewed.
  • Working with migrations that reference apps that have since been removed
  • All Django monkeypatching and internals fiddling moved into a separate module.
  • New pre_migrate and post_migrate signals

There have also been many bugfixes for various edge cases or odd fields; for the full lowdown, we invite you to read through the commit history, or see the list of closed tickets.

Known issues:

  • The automigrator will not correctly detect alterations of normal columns into ForeignKeys? and vice-versa; you will need to add a db.rename_column command into both methods of the generated migration.
  • If you are upgrading from 0.5, the automigrator may detect spurious changes that haven't actually happened, because our frozen format has changed. If this happens to you, simply create a new blank migration using ./ startmigration appname dummy_migration, and then use --auto from there on.

Backwards incompatable changes:

  • The ORM instance passed to the backwards() method now uses the models from the previous migration (or no models if that migration is the first). This should not affect many users; however, if you have combined a data and schema migration, look out.