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 introducing a dangerous type of migrationâthat is, 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 confidence 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 Chapter 17:
$ cd deploy_tools $ fab deploy:host=elspeth@superlists-staging.ottg.eu [...] Running migrations: Applying lists.0005_list_item_unique_together...Traceback (most recent call last): File "/usr/local/lib/python3.6/dist-packages/django/db/backends/utils.py", line 61, in execute return self.cursor.execute(sql, params) File "/usr/local/lib/python3.6/dist-packages/django/db/backends/sqlite3/base.py", line 475, in execute return Database.Cursor.execute(self, query, params) sqlite3.IntegrityError: ...
Get Test-Driven Development with Python, 2nd Edition now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.