For the record, here is the ticket:
https://code.djangoproject.com/ticket/16329
Best regards,
Cesar Canassa
2011/6/24 Russell Keith-Magee <russ...@keith-magee.com>
> 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.
>
>
--
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.
