On Fri, Jun 24, 2011 at 2:08 PM, Cesar Canassa <cesar.cana...@gmail.com> wrote:
> I think I solved this! The reason why the test cases were taking so long was
> because Django was not enabling the transaction support, so the tests were
> falling back to the non-transaction TestCase
> My project has two test databases but the 'log' is not used anymore so I
> didn't care if it was created or not:
> DATABASES = {
> 'default': {
> 'ENGINE': 'django.db.backends.sqlite3',
> 'NAME': ':memory:',
> },
> 'log': {
> 'ENGINE': 'django.db.backends.sqlite3',
> 'NAME': ':memory:',
> }
> }
> When the tests run it calls the following method:
> def connections_support_transactions():
> """
> Returns True if all connections support transactions. This is messy
> because 2.4 doesn't support any or all.
> """
> return all(conn.features.supports_transactions
> for conn in connections.all())
> In Django 1.2.3 this method returns all([True, True]) and in Django 1.3 it
> returns all([True, None])
> The problem is that in my test settings I used the same database name
> ':memory:' on both databases. When this happens in Django 1.2.3 it
> initialize the both databases, but in Django 1.3 it doesn't initialize the
> second. I just had to change the names and now the tests are running back in
> the usual speed!
> This was very hard to debbug, maybe Django should include a warning message
> in case someone tries to do this mistake again?
Ah - you didn't say you had two databases. There *were* some very
important changes made to the test setup mechanism for 1.3 when
multiple databases are involved, and they certainly explain the
behavior you're seeing.
Under 1.2.X, if you have multiple databases, and multiple entries
pointed to the same database name, the test database would be
initialized twice. If you were using an on-disk database (rather than
:memory:), this would lead to the creation of *two* test databases,
instead of one test database with two connections. To make matters
worse, under certain conditions, the teardown process would cause the
*production* database to be dropped.
In 1.3, we use a combination of database name, host, port and engine
(and, in the case of Oracle, the username as well) to identify the
'unique' databases, and ensures that each of these test databases are
only initialized once, and the connections are then patched to make
sure you have multiple connections to a single database.
So - it sounds like you might have found a bug, not just something
that needs to be documented. :memory: databases don't behave quite
like on-disk databases, but we don't have any special handling in
place to account for that fact.
If you could open a ticket for this, I'd be much obliged.
It sounds like you've found a temporary workaround; for the record,
another workaround would be to put *anything* into the HOST or PORT
settings for your database. That would be enough to mark the two
databases as distinct from the perspective of the test setup
mechanism.
Yours,
Russ Magee %-)
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
