#14415: Multiple aliases for one database: testing problems
---------------------------------------------+------------------------------
Reporter: shai | Owner: nobody
Status: new | Milestone:
Component: Testing framework | Version: 1.2
Resolution: | Keywords: multidb,
multiple databases, multiple aliases
Stage: Design decision needed | Has_patch: 0
Needs_docs: 0 | Needs_tests: 0
Needs_better_patch: 0 |
---------------------------------------------+------------------------------
Changes (by ramiro):
* stage: Accepted => Design decision needed
Comment:
This is what I've found:
I think the maximum that Django can provide is what I've tried to
implement in the patch:
* Make sure no cross pollution of `DATABASES['alias']['NAME']` and
`DATABASES['alias']['TEST_NAME']` happens between DB aliases/connections,
even when they are described by the same Python dict so in no event the
production `DATABASES['alias']['NAME']` DB gets removed.
* Don't report an error if the test database doesn't exist when trying to
drop it (or, for SQLite3, don't try to remove the DB file).
What's described above is generally applicable to Postgres, MySQL and
SQlite3.
But after fixing that, there are other problems (at test DB teardown
time): In Postgres and MySQL the test databases are removed by using the
production one as a pivot (a connection is made to the production DB and
from there the test one is DROPped). If you get the setup you describe, it
might happen (It happens to me) that 'default' will get is test DB
('test_main') dropped and when 'other' tries to connect to its production
one to do the same (remove it 'test_test_main' DB) it won't find it.
Solving this means Django would need to detect and keep track of the fact
that one alias' test DB name is the same as other alias' production DB,
and DATABASES being a dict, there is no guaranteed order of
creation/removal of DBs.
The conclusion I get is this is what you describe as the ''The more
dangerous case'' and ''one may expect this to be the common use case in a
multiple-aliases-for-one-database approach'' is enough of an edge case
that can't be completely solved by Django. If you really need to create
more that one DATABASES aliases to the same database and you decide to
represent them by pointing them to the same dict, then maybe you will need
to implement your own test runner that will need to have some inside
knowledge of this and e.g. will need to setup/tear down the test DBs in
the right order, etc.
The Oracle backed has its own tools so (again) the user, not Django, tries
to implement a workaround to the scenarios you describe (see
wiki:OracleTestSetup ''Understanding the database test setup'' section.)
--
Ticket URL: <http://code.djangoproject.com/ticket/14415#comment:2>
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.
