If you have worked on a project in Django, you have undoubtedly discovered that ‘syncdb’ is great at turning your ‘models.py’ files into real database tables but not so great at taking your modified models and altering your database with the new definitions. In fact, the Django documentation is pretty clear about this: “Syncdb will not alter existing tables”!
South is a Django project which solves this problem by providing “consistent, easy-to-use, database-agnostic migrations for Django applications.” Below are the most basic steps for getting South up and running in your project.
INSTALLING SOUTH
- pip install south (if you’re lucky, otherwise RTFM)
- add ‘south’ to your project’s INSTALLED_APPS
- run ‘syncdb’ (before you create your own models)
- note: this is the last time you’ll run ‘syncdb’
YOUR FIRST MIGRATION
- create a new app and create your initial ‘models.py’ file for it
- add your app to your project’s INSTALLED_APPS
- run ‘python manage.py schemamigration myapp –initial’ (creates your initial migration, note: those are two dashes hyphens before initial)
- run ‘python manage.py migrate myapp’ (uses this initial migration to create your app’s DB tables)
MIGRATING A CHANGED MODEL
- modify your app’s models.py file (e.g., add a new column somewhere)
- run ‘python manage.py schemamigration myapp –auto’ (creates a new migration, note: those are two dashes hyphens before auto)
- run ‘python manage.py migrate myapp’ (applies this new migration)
That’s it, the very bare bones steps to getting up and running with South. Obviously you’ll either need to run these commands in the same directory as ‘manage.py’ or change the commands to point to it.
One last thing…
AN OPTIONAL SHELL FUNCTION TO HELP OUT
- vi ~/.bash_aliases (there’s probably a better home for this, but this is where I put mine)
- add:
function mig() { python manage.py schemamigration "$@" --auto; python manage.py migrate "$@"; } - source .bash_aliases (to activate the changes)
- now you can run ‘mig myapp’ whenever you change the model for ‘myapp’
If you want to be able to run this shell function anywhere, put the full path to your project’s ‘manage.py’ file in the function body. Otherwise, you’ll have to run it in the same directory as the relevant ‘manage.py’.
For South’s more advanced goodness, check out the documentation.
South 0.7
Django 1.2.1
Python 2.5.2.
I'm a builder. I love to build things for work and for fun.
6 Responses to “Getting Started with South (Django Database Migrations)”
Thank you for this! I think the documentation is somewhat vague on this subject. Nice to see it explained so easy.
A few months ago the documentation of South was ugly, but then it was refactored and now it’s pretty simple and understandable – http://south.aeracode.org/docs/.
It has also enough amount of examples, so there isn’t real need to explain how to work with South on other sources.
Thanks for function mig(), but autocomplete in Django 1.2 rules too
I’ve been hesitant to try South, preferring instead to write my own SQL scripts for migration. Thanks for making the water seem less intimidating. I’m going to give it a go at work.
Those should be two hyphens preceding the “initial” switch, not two dashes. A dash is longer than a hyphen. There’s no dash in ASCII, so traditionally, the dash is represented by two hyphens. See the documentation for Python’s getopt module for more about command line argument processing in Python.
on June 25th, 2010 at 5:35 pm #
[...] put off using for too long. Looking back, it is so easy to get up and running (just like South was, see below) that there is no reason for you to hold off like I [...]
on July 7th, 2010 at 3:27 pm #
[...] Getting Started with South (Django Database Migrations) | Mitch Fournier – [...]