Ok, today was the second time I was bitten by this. Time to write down the solution so I can find it back in google :-)
The problem occurs when you have multiple databases, with the second one being just for one app. For example an existing database from the customer with some read-only data. So you probably have one app just for reading that data with a database router that allows only that app’s models in that database. What happens when you have south enabled and you run the tests:
$> bin/test ... Creating test database... Syncing... Creating table aaa Creating table bbb ... No fixtures found. Migrating... Running migrations for ccc: - Migrating forwards to 0001_initial. ... No fixtures found. Synced: > aaa > bbb Migrated: - ccc Creating test database 'the_second_database'... Syncing... Creating table ddd Creating table eee No fixtures found. Migrating... Traceback (most recent call last): ... django.db.utils.DatabaseError: no such table: south_migrationhistory
Well, yes, that
south_migrationhistory table doesn’t exist in the second
database. It doesn’t need to be. When creating/migrating the databases
(outside the tests), it all goes perfectly OK as only the default database is
getting created/migrated. Only south in combination with tests fails as both
databases need to be created/migrated to run the tests.
The workaround: add
SOUTH_TESTS_MIGRATE = False to your
settings.py to switch off south usage during tests.
I read that south’s multiple database support isn’t fully matured. The routers aren’t used yet for autodetecting the proper behaviour, for instance, in so far that would be possible. Anyway, the workaround works for now :-)
I’ve opened a ticket for it.
My name is Reinout van Rees and I work a lot with Python (programming language) and Django (website framework). I live in The Netherlands and I'm happily married to Annie van Rees-Kooiman.
Most of my website content is in my weblog. You can keep up to date by subscribing to the automatic feeds (for instance with Google reader):