#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: 0 | decision needed
Needs tests: 0 | Needs documentation: 0
Easy pickings: 0 | Patch needs improvement: 0
| UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by akaariai):
* cc: anssi.kaariainen@… (added)
Comment:
I am going to wait what happens to #17258 before working on this. I am
afraid working on this will be wasted work if that one gets committed.
But, just to make sure: it is OK if the setup isn't restored for all
threads after the test suite has ran? The settings dict change would
restore the non-testing database settings only for the main thread. I
don't think it is possible to solve this in a way that:
- blocks test threads from ever accessing the production DB
- allows threads started after the tests have ran to access the
production DB
- allows usage of normal threads (instead of test.utils.threading) in
the tests
The reason is that if a test-thread makes its first use of a connection
after the tests have ran, there is no way to tell it apart from a thread
that has been started after the tests have ran.
--
Ticket URL: <https://code.djangoproject.com/ticket/10868#comment:7>
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.
