Opened 6 years ago

Closed 6 years ago

#11987 closed (invalid)

destroy_test_db can destroy the production database in some situations

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


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:

    test_database_name = settings.DATABASE_NAME
    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
        test_database_name = TEST_DATABASE_PREFIX + settings.DATABASE_NAME

Change History (1)

comment:1 Changed 6 years ago by russellm

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Resolution set to invalid
  • Status changed from new to closed

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.

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