#14415: Multiple aliases for one database: testing problems
-----------------------------------------------------------+----------------
Reporter: shai | Owner:
nobody
Status: new | Milestone:
Component: Testing framework | Version: 1.2
Keywords: multidb, multiple databases, multiple aliases | Stage:
Unreviewed
Has_patch: 0 |
-----------------------------------------------------------+----------------
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>
}}}
--
Ticket URL: <http://code.djangoproject.com/ticket/14415>
Django <http://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/django-updates?hl=en.
