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
<blockquote style=""padding-left: 3em;"">
 ...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.
</blockquote>
}}}
"	Bug	closed	Testing framework	dev	Normal	fixed	multidb, multiple databases, multiple aliases		Accepted	1	0	0	0	1	0