On Fri, Jan 16, 2009 at 9:13 AM, Ivan Sagalaev
<man...@softwaremaniacs.org>wrote:
>
> 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.
Yes, that's an interesting case, and certainly not one covered in my
testing.
If you actually want to test that your master/slave setup is working and
doing all the right stuff with commits getting shadowed to the slave, a
TransactionTestCase should work for that. But for the bulk of your tests
that are actually testing other stuff, limiting the test to using one
connection sounds like a good idea.
Karen
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
