Migrating with South
Here at Torchbox we work on quite a few Django projects, so when we were faced with making an enterprise-level project, we had to tackle and overcome the traditional Django problem with schema migration.
We love our Django here at Torchbox, but one of the problems that's got us several times is the problem of database schema changes - when you add a new column to your user profile table, say, or separate some fields out into their own model.
With The Carbon Account, we tackled this with a simple SQL-based migrations system with a global version number. This simple approach is taken by a lot of migration systems out there today, but during development we came across a few problems with it. Nevertheless, it worked well enough.
However, as we embark on our next big project, we wanted to tackle the problem properly. Faced with django-evolution as the only sane option, it didn't really fit our needs, and so we invested some development time in creating South, a new Django migrations framework.
South has three things that set it apart - it can tell when migrations appear out-of-order (i.e. there are gaps in the migrations applied when you update and a new one comes in - a bigger problem the more developers you have), it's database-agnostic, so we can develop on PostgreSQL and deploy to whatever database the client wants, and it can also generate the simpler migrations for you, saving you hassle.
After a day or two, we had something that integrated well with syncdb so not all apps had to be migrated, that generated the inital migrations for us, and that's already helped us migrate successfully twice. We'll be giving it a good testing on our new project, and some other people have already picked up on it and are trying it against their systems too; perhaps painless migrations will soon be the norm (we can only hope).
South is open-sourced; if you're a Django developer and you want to give it a try, or perhaps even contribute, have a look at the project website.
