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)

testmirror-sqlite.diff (645 bytes ) - added by adsva 12 years ago.

Download all attachments as: .zip

Change History (3)

by adsva, 12 years ago

Attachment: testmirror-sqlite.diff added

comment:1 by adsva, 12 years ago

Component: UncategorizedTesting framework
Type: UncategorizedBug

comment:2 by Łukasz Rekucki, 12 years ago

Resolution: wontfix
Status: newclosed

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).

Note: See TracTickets for help on using tickets.
Back to Top