Development with Python

455 / 478

APPENDIX D
Testing Database Migrations
Django-migrations and its predecessor South have been around for ages, so it’s not
usually necessary to test database migrations. But it just so happens that we’re intro‐
ducing a dangerous type of migration, ie one that introduces a new integrity constraint
on our data. When I first ran the migration script against staging, I saw an error.
On larger projects, where you have sensitive data, you may want the additional confi‐
dence that comes from testing your migrations in a safe environment before applying
them to production data, so this toy example will hopefully be a useful rehearsal.
Another common reason to want to test migrations is for speed—migrations often
involve downtime, and sometimes, when they’re applied to very large datasets, they can
take time. It’s good to know in advance how long that might be.
An Attempted Deploy to Staging
Here’s what happened to me when I first tried to deploy our new validation constraints
in :
$ cd deploy_tools
$ fab deploy
[...]
Running migrations:
Applying lists.0005_list_item_unique_together...Traceback (most recent call
last):
File "/usr/local/lib/python3.3/dist-packages/django/db/backends/utils.py",
line 61, in execute
return self.cursor.execute(sql, params)
File
"/usr/local/lib/python3.3/dist-packages/django/db/backends/sqlite3/base.py",
line 475, in execute
return Database.Cursor.execute(self, query, params)
sqlite3.IntegrityError: columns list_id, text are not unique
[...]
427