Using a Test Database in Django

Seán Hayes — Sat, 09 Jan 2010 14:27:07 +0000

As I mentioned in my previous post, we’re using MySQL on our development machines. It has several advantages, but one of the drawbacks is unittests run slower when not using Sqlite (big ups to MockSoul for posting his benchmarks). The reason for this is when running unittests in Django with a Sqlite database, the database is run in memory (RAM) instead of being written to the disk.

Django only allows you to specify one database, and although a new database is created for unittests, it still uses most of the same settings (auto prepending “test_” to the database name), which means a Django install using MySQL also uses MySQL for unittests.

To get around this problem, I created a file in my project root called test_settings.py containing the following lines:

I then opened my settings.py, imported sys, and inserted the following lines at the end of the file:

If one of the command line arguments is “test”, that means a unittest is being run, in which case Django will attempt to import test_settings.py, which will override the database settings and use Sqlite instead. Migrations won’t be an issue, since Django South uses the old syncdb command for generating databases for unittests.

Hope this helps you save some time testing.

Cross Database Incompatibility Using Django South

Seán Hayes — Sat, 09 Jan 2010 14:11:12 +0000

When our team (at Govnex) started using South Migrations we encountered a cross-database compatibility issue. I was using MySQL on my local machine for its performance and so I could browse the database using phpMyAdmin, while our other members were using Sqlite on their local machines. The problem we encountered was migrations that worked my machine running MySQL were failing on their machines running Sqlite. We discovered the cause was some NOT NULL fields in our models which didn’t have defaults defined; the NOT NULL fields with no defaults were working fine in Sqlite when created using syncdb, so apparently it’s only when updating a table in Sqlite that they require defaults (this a caveat of Sqlite, not Django South).

Our immediate solution was to add default values to the necessary fields. However, in the end we decided to switch to MySQL on our development machines in order to ensure no future issues arise that might prevent our development code from working on our production server, which also runs MySQL. Hope this helps anyone who might be having the same issue.

Seán Hayes' Blog » sqlite

Using a Test Database in Django

Related posts

Cross Database Incompatibility Using Django South

Related posts