#10868: _destroy_test_db exposes the production database to possibly destructive
actions from the unit tests
-------------------------------------+-------------------------------------
Reporter: ovidiu | Owner: nobody
Type: Bug | Status: new
Component: Testing framework | Version:
Severity: Release blocker | Resolution:
Keywords: django.test | Triage Stage: Design
Has patch: 1 | decision needed
Needs tests: 0 | Needs documentation: 0
Easy pickings: 0 | Patch needs improvement: 0
| UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by akaariai):
At least when using PostgreSQL, you need to connect to some database to
issue any commands. That includes creating the test database. You can't
drop a database somebody is connected to, and that includes dropping the
test database from the test database. I am not sure about this, but Oracle
is likely going to be even more problematic.
What could be done however is _not_ restoring the connection state after
tests have ran. How backwards incompatible that would be is a good
question. But not having a connection to the production database at all is
even more backwards incompatible.
If the restoring of connection settings is not done, you would basically
do the following in teardown: 1) close all existing connections, 2) alter
the database wrapper for the main thread's connection settings. 3) take a
new connection to the production DB, 4) drop the test databases 5) revert
the changes to the running thread's database wrapper.
Now, the changes to the database wrapper are only for the test-db dropping
thread. Other threads' connection settings are not altered. Thus, you will
not expose the production database to other threads than the test-db
dropping thread. The no.5 above is actually making the connection wrapper
invalid, as connecting to the non-existing test database is not possible.
Checking that there are no threads running seems like a bad idea to me
now. I wonder what would happen when using for example Jython. If I am not
mistaken, Jython uses a lot of threads.
It should be somewhat easy to just disable _any_ connections to anywhere
after tests have been executed. That would be the safest way :)
--
Ticket URL: <https://code.djangoproject.com/ticket/10868#comment:14>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/django-updates?hl=en.
