Opened 6 years ago

Last modified 6 years ago

#29225 closed Bug

The non-test sqlite database can be easily destroyed during tests — at Initial Version

Reported by: gh720 Owned by: nobody
Component: Testing framework Version: 1.11
Severity: Normal Keywords:
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

I don't know if it is a bug or just a nasty feature, that appears to be undocumented, or a well known caveat that I don't know about.

With a few seemingly innocent steps you can get your working sqlite database destroyed during tests.
Suppose you hold a few database configs in settings.DATABASES:

DATABASES = {  'sqlite1': { ... }, 'sqlite2': { ... } }

And you want to select one and leave it as the default.
The simplest solution that comes to mind is
DATABASES['default'] = DATABASES['sqlite1'] .

And now there is a funny piece of code

https://github.com/django/django/blob/master/django/db/backends/base/creation.py
...
# Restore the original database name
        if old_database_name is not None:
            settings.DATABASES[self.connection.alias]["NAME"] = old_database_name
            self.connection.settings_dict["NAME"] = old_database_name

Suppose we run a test.
In case of in-memory sqlite testing the "url" of in-memory database (something like file:memorydb_sqlite?mode=memory&cache=shared gets replaced with the real sqlite db file path by the code above.
Guess what happens in the second iteration?
Real sqlite db is destroyed.

May be this one is well known and every developer is aware of that?
But still it is to easy to step into this trap in my opinion.

I guess it should be documented somewhere or the code above somehow amended.
(I don't know Django well enough to say whether that restoring old name is necessary or not)

Change History (0)

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