Karen Tracey wrote:
> Hmm, not sure what is going on here. Django's admin_views testscase
> uses client and fixtures, and doesn't have a problem. It should not
> happen that data loaded by one TestCase persists in the database to
> another test. TestCase setup starts a transaction and disables access
> to the transaction routines, so commits done by the called code don't
> actually get committed. TestCase cleanup rolls back the transaction
> started by TestCase setup. So I'm concerned how you are getting bleed
> over from one test to the next...that shouldn't happen.
I've found it. My fault, as usually :-). But an interesting corner case
too.
We're using mysql_replicated db backend that basically has two
connections. The first ("master") is active by default and is used when
loading fixtures. Then a test calls a db-read-only view and all its
interactions with the db go intto another ("slave") connection which
doesn't see any data changed in the master because it didn't commit.
Thus a test fails because the db is absolutely empty.
Now I'm going to implement a switch for the backend ensuring that only
one connection is used and it'll be used in test environment.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
