id summary reporter owner description type status component version severity resolution keywords cc stage has_patch needs_docs needs_tests needs_better_patch easy ui_ux 14415 Multiple aliases for one database: testing problems Shai Berger Boaz Shvartzman "In a setting where the multiple-databases feature is used to create multiple aliases for one database, the testing framework can get a little confused. For ease of reference, assume we have the following dictionary defining database parameters: {{{ db_params = dict ( NAME = 'main', ENGINE = 'django.db.backends.whatever', USER = 'user', PASSWORD = 'password', HOST = '', PORT = '' ) }}} == The relatively benign cases == In these cases, the test framework just treats the two aliases as separate databases; which means it first creates the test database for one alias, then tries to create the test database for the second one, running into an error because (of course) it already exists. The user is asked to choose between destroying the existing database (in order to recreate it) and canceling the test. In cases where database routers constrict models to a specific alias, this may completely prevent testing (or at least some of the tests). This happens if at least one of two conditions hold: === The dictionaries used to define the alias are distinct === That is, the databases are defined by {{{ DATABASES = { 'default' : db_params, 'other' : db_params.copy() } }}} or some equivalent === Test name is explicitly specified === That is, `db_params` looks like: {{{ db_params = dict ( NAME = 'main', TEST_NAME = 'test_main', ... # same as above ) }}} The databases may then be specified by the more natural {{{ DATABASES = { 'default' : db_params, 'other' : db_params } }}} == The more dangerous case == In this case, the testing framework creates spurious databases and finalizes be destroying the main, non-test database. This happens when none of the above applies -- that is, `db_params` does not include the `TEST_NAME` entry, relying on the default `test_` prefix addition, and databases are specified by two references to the same dictionary (as in the last definition above). Regretfully, one may expect this to be the common use case in a multiple-aliases-for-one-database approach. In detail: With the definitions above, the testing framework first creates a `test_main` database, then a `test_test_main` database, and runs its tests with both of them present; then, during tear-down, it drops the `test_test_main` and *`main`* databases, leaving `test_main` in place. == A word for fixers == For whoever wants to work on this ticket (perhaps myself...), Russel Keith-Magee has [http://groups.google.com/group/django-developers/browse_thread/thread/f3fac51f7ec56dfa said] that {{{ #!html
...this almost rates as an 'easy pickings' ticket. This is a situation where you'll get a pass on having a test as part of the patch; testing test setup is one of those areas that's almost impossible to validate, so whoever commits (probably me) will just take it for a very good walk before checking in.
}}} " Bug closed Testing framework dev Normal fixed multidb, multiple databases, multiple aliases Accepted 1 0 0 0 1 0