Non-obvious beginners hint for development with Django and South
South is the migration framework used with Django. It’s good, use it.
However, it’s a bit awkward to use in the beginning, because the intro documentation doesn’t mention one thing, although it has to be said that it becomes obvious once you learn more about South.
When starting out developing you change the model schemas a lot. So you end up doing a lot of migrations, and having a big stack of migration steps. But the problem is that you often have data in your development database that can’t easily be migrated. But it’s a development database, so the data doesn’t actually need to be migrated. So you have to open up the Django admin, delete the problematic data and then do the migration. In bad cases it becomes easier to just drop the whole database.
Well, it turns out there is an easier way to do that:
Instead of making new migration steps for every change, just first make an initial migration step:
python [yourproject]/manage.py schemamigration [yourapp] --initial
Then, each time you need to change the schema, instead of making a new migration, update the first initial one:
python [yourproject]/manage.py schemamigration [yourapp] --initial --update
This well first back out the old initial migration, in practice clearing the app database, and then regenerate the initial migration. When you then run the migration, it will create a new empty database.
python [yourproject]/manage.py migrate [yourapp]
That means you have to recreate the test data. You can do that by making test/demo data once, and dump it.
python [yourproject]/manage.py dumpdata [yourapp] --indent=4 > [yourproject]/[yourapp]/fixtures/test_data.json
After you change the schema, you will have to update the schema in the test_data.json file as well, but then you can load it into the database:
python [yourproject]/manage.py loaddata test_data
As an addition bonus, you now have fixture data for your tests!
You can keep using
--initial --update until you start installing a staging server. At that point you need to have proper migrations as people will put data into the staging server. It might not be real production data, but they might get annoyed if it disappears. The you can use
--update for all the schema changes you do between two releases, so all the changes in one release only need one upgrade step.