On 3 syys, 03:17, Jeremy Dunck <[email protected]> wrote: > I have been working on a master/slave router library [1] and have run > into some trouble testing a client application of it. > > The issue is that TestCase (as designed) holds test db writes in a > transaction, but the read slave connection (which is to the same DB > under TEST_MIRROR) does not have visibility to the changes (at least > in READ COMMITTED isolation). > > For example, if I save a model instance to the master and then attempt > to read from the slave, it won't be there because the test transaction > is still pending. > > Has anyone else had success testing master/slave with Django? I think > a solution probably belongs in core. > > Options I can see to address this: > 1) change TEST_MIRROR'd aliases to use the same underlying DB > connection while under test > 2) switch all tests to TransactionTestCase > 3) switch isolation visibility under test > 4) give up hitting replicas under test (that is, have an IS_TEST > branch in the router). > > Of these ideas, the 1st is the most appealing to me - it'd mean some > jiggery to not repeatedly close/teardown the DB, but otherwise likely > would be transparent. > > 2) would have a very bad performance impact. > 3) would potentially have bad interactions with some applications. > 4) would be a doc change but we'd perhaps need a standard way to > indicate the test context - and also the icky feeling of branching > under test in the app code.
Part of the problem is that the writes really aren't visible in the slave database until committed. By using the same connection you would make this important distinction go away. Isolation level change will not work in general, as reading in- transaction stuff isn't supported in most of the databases. Routing the database connections differently will not work unless one uses the same connection to begin with, and then you have the problem of using the same connection... Using the same connection is OK for me, but only if the user explicitly asks for it per test case. Doing it automatically will make the test environment significantly different from the production environment. I would like to make the TransactionTestCase faster. Currently when running Django's test suite, for every test ran you will truncate around 1000 tables, then create around 4000 objects (permissions + content types). Likely you will write to one or two tables in the test, and then do the truncate/recreate dance again. There is room for improvement. Track which tables have been modified and refresh only those tables. - Anssi -- You received this message because you are subscribed to the Google Groups "Django developers" 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-developers?hl=en.
