Migrating the future - Andrew Godwin¶

Tags: django, djangocon

Andrew Godwin attempted to raise 2500 pounds for inclusion of south in Django core with kickstarter. It worked. In fact, he raised 17952 pounds!

Why does South need to be replaced by a new version inside Django itself?

• It started 5 years ago, so there’s 5 years of learning done in that period. Some things that made sense at the time aren’t the best decision now.

• There’s poor support for VCS branching.

• The migration files are huge.

• Migration sets get too large. There are projects with 1000 steps!

The inside-django solution has two parts. The actual migration code and a separate backend. So if you want a different migration engine, you can probably reuse the backend code with its support for multiple types of databases.

The new migration format is more declarative instead of imperative like it is now. This makes them smaller. It also allows you to compute the end result in memory and apply one single migration.

Migrations will have a parent. So you won’t have a problem with 0003_aaaa and 0003_bbbb migrations that halfway bite eachother. If a merge can be done automatically, fine, otherwise south/django will warn you.

Squashing will be added. You can squash a set of migrations together so that you can start from one new starting point instead of needing to go through the entire list of migrations.

One thing to watch out for: the Django field API will change a bit because the migration code needs to know how to re-create a field. Watch the django developer mailinglist if you’re interested.

Read his blog at http://www.aeracode.org/ if you’re interested in the details of everything he encounters.