Opened 12 years ago
Closed 12 years ago
#18813 closed Bug (wontfix)
TEST_MIRROR functionality broken for sqlite
Reported by: | adsva | Owned by: | nobody |
---|---|---|---|
Component: | Testing framework | Version: | 1.4 |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Unreviewed | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
I do understand that SQLite doesn't really support replication, so the test_mirror setting might be a little silly, but I'm using postgres with a master/slave setup in production and would like to use SQLite when running the tests for simplicity and performance. Following what seems like a somewhat common practice of switching the DATABASES setting for testing:
if 'test' in sys.argv: DATABASES = { "default": { "ENGINE": "django.db.backends.sqlite3", }, "slave": { "ENGINE": "django.db.backends.sqlite3", 'TEST_MIRROR': 'default', }, }
But when I try to use connections['slave']
after database initialization is done in the test runner I get an uninitialized in-memory database, and not the connections['default']
database. The reason seems to be that the test runner just copies the name and features of the 'default' connection to the 'slave' connection. I guess this is sufficient for the other database engines, where the name ensures the connections use the same database, but each SQLite connection to ':memory:' gets its own database.
The attached patch changes that behavior to simply point connections['slave']
to connections['master']
, and that seems to solve the problem, but maybe there was good reason for the current behavior?
Attachments (1)
Change History (3)
by , 12 years ago
Attachment: | testmirror-sqlite.diff added |
---|
comment:1 by , 12 years ago
Component: | Uncategorized → Testing framework |
---|---|
Type: | Uncategorized → Bug |
comment:2 by , 12 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
If both databases use the same connection, they also share transaction state. This isn't what you will get on your production environment.
As for SQLite, unability to create more then one connection to a
:memory:
database is a known limitation, that can't be solved by Django. You can use a file database instead (hint: which you can create on a in-memory filesystem for performance).