destroy_test_db can destroy the production database in some situations

[eronen]

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

[Russell Keith-Magee]

I'm unclear of the sequence of events that can cause this to be a problem. If you hit Ctrl C, the python process is killed. Unless I'm missing something, the value stored in settings.DATABASE_NAME at that point is irrelevant - it won't be shared with anything, or used by anything that could destroy data.

I'm also unclear which code you are updating. If you want to submit a patch, use diff.