Currently using Django “Evolution”, is “South” better and worth switching?

问题

I'm currently using Django evolutions to manage my product's database evolutions. It's not perfect but I've learned to live with its flaws. For instance, I always have to copy my production database to test before moving out a new schema because the "evolve" command cannot always evolve a database that was changed in several small migrations (on test I did A->B->C, but A->C will not evolve correctly.)

Will South fix all of those problems? Is it worth the effort of learing a new tool?

回答1:

I just started using South, and I'm 100% sold on it. It's also one of the few that's still under very active development.

South should be able to properly handle the issues you've describe above. For each change to the db, it creates a file that has 2 methods "foward" and "backwards". Here's a sample automatically generated migration:

# > manage.py schemamigration issuetracker added-status-field --auto

# 0004_added-status-field.py
class Migration:

    def forwards(self, orm):

        # Adding field 'Issue.status'
        db.add_column('issuetracker_issue', 'status', orm['issuetracker.issue:status'])       

    def backwards(self, orm):

        # Deleting field 'Issue.status'
        db.delete_column('issuetracker_issue', 'status')

A couple of the nice things about it....

• South lets you rollback to a specific migration # if you'd like

• If your production site is on migration 0002 and your SVN commit is on 0004, South will do 0003 then 0004 to bring the production db up to speed.

• If you've gone ahead and made the changes yourself, you can tell South to run a 'fake' migration. Normally a migration system would throw a hissy fit, but this makes it really easy to have flexible control over your db.

  manage.py migrate [appname] --fake

• If you need to have something custom happen, like say copying the data in a column to another column, because the migration files are just python files it's easily to modify the forward/backwards functions.

• Migrating to South after having already deployed an application was rather easy. The latest version 0.6 includes a command for it actually.

  manage.py convert_ to _south [appname]

• And of course, how could I forget, my favorite feature is the automatic generation of migration files

  manage.py schemamigration [appname] [description] --auto

---

Gotchas

I figured I should add in some tips for mistakes I made when getting started with South. Not everything is 100% intuitive.

• After you've run the convert_to_south command on your development database, don't forget to run migrate --fake on your production database, otherwise South will think it's out of date.

• If you're creating a new app, you use the --initial flag

• Stop using manage.py syncdb. Really.

• Editing a model is a 3 step process --

  1.) save the model changes

  2.) run schemamigration --auto

  3.) run migrate to actually commit the changes to the database

Edit -- To clarify the comments below, South was officially voted by the core contributors to not be included with Version 1.2. This was in part because the author of South had requested that it not yet be included. Even still, there is a lot of community support for South, and some reusable app makers are beginning to include South migrations with their app.

Edit #2 -- I made some updates to reflect the new manage.py command structure from the current trunk version of South. "startmigration" has been split to "schemamigration" and "datamigration" depending on what you're doing.

来源：https://stackoverflow.com/questions/1590944/currently-using-django-evolution-is-south-better-and-worth-switching