destroy_test_db can destroy the production database in some situations
|Reported by:||eronen||Owned by:||nobody|
|Has patch:||no||Needs documentation:||no|
|Needs tests:||no||Patch needs improvement:||no|
I have some tests which need to be run against the production database, so these test cases temporarily change settings.DATABASE_NAME. If those get interrupted (by e.g. Control-C) in the wrong place, settings.DATABASE_NAME might be left pointing to the production database.
Ticket #10868 describes another situation (involving threads) where destroy_test_db could end up destroying the wrong database.
There might be other reasons why this could happen. I would suggest rewriting this line in a bit safer way to avoid this ituation. Perhaps something like this:
OLD: test_database_name = settings.DATABASE_NAME NEW: if settings.TEST_DATABASE_NAME: test_database_name = settings.TEST_DATABASE_NAME elif settings.DATABASE_NAME.startswith(TEST_DATABASE_PREFIX): test_database_name = settings.DATABASE_NAME else: test_database_name = TEST_DATABASE_PREFIX + settings.DATABASE_NAME