Yousef Ourabi

The Schema Migration panel by: Simon Willison, Russ Keith-Magee, Andrew Godwin, and  moderated by Michael Trier was an interesting sampling of the various methods used in schema migration.

Simon Wilson presented dmigrations . Installing dmigrations is as simple as installing it in INSTALLED_APPS, and it will registers a few custom admin commands:

./manage.py dmigrate app APP_NAME

./manage.py dmigrate list

./manage.py dmigrate addcolum

My take: dmigrations is great and will work for migration problems right now, but in its current form is unlikely to end up in django as the annointed migration solution. Why? Because it basically wraps SQL directly, loosing some of the cross-database portability of the Django DB.

Andrew Godwin: South — described as the next step of dmigrations. Philosophy: Migrations are essential, branched development / missing migrations, inter-app dependencies, database abstraction needed too. Can handle model dependency (foreign keys.)

My Take: worth looking into, more database indapenent.

Russel Keith-Magee: Django-evolution, his response to a mailing list thread that would not end. Google Summer of code 2006. Russel complaining of Magic moniker attached to django-evolution, everything done via introspection of models. Goals: Hint and Tweak, Simple changes without user intervention, easy entre for customization, raw sql, self documenting, self auditings, Validation (where possible).

Signature: pickled summary of django model. Stores state of django models at syncdb, can be diffed against current models, diffs used to generate hints.

Mutation: Atomic unit of change, common operations built in. Can be user-defined, can be raw sql, know the effect they will have.

Evolution: Ordered collection of mutations. Two flavors of mutations: hinted and stored. Executed evolutions stored in database.

Hinted Evolution: Best guess by looking at diff, if acceptable can be used to execute evolution right away. Can also be used as prototype to stored evolution. Can’t resolve ambiguous updates (rename) can’t fill in the blanks (initial data)

Stored Evolution:
Named sequence of mutations. Defined per application, stored in evolutions directory of app (can be put into version control).

django-evolution extends syncdb — as in ./mange.py syncdb — schema change detected you need an evolutions.

Custom commands:

./manage.py evolve –hint

./manage.py evolve

My Take: Highly interesting, most likely to end up in django. Grok this.

Filed under: Programming