On Tue, May 31, 2011 at 02:01:00PM -0700, Brian wrote: > I've got a django app with a periodically scheduled background task that > updates the database. I've written a bunch of tests for its principal class > that are run as part of the django unit test framework. I want to convert > the class to do its work using multiple threads, but I'm having trouble > getting the tests to run against the multi-threaded version. > > I've tried sqlite3 and postgres as back-ends, but to no avail. Is there a > problem where the testing framework uses transactions to rollback any > changes from one test to the next and so the evolving state of the database > in that transaction is hidden from the other threads?
Right. > Can the database connection (and hence transaction) be shared between > the threads? Has anyone encountered this problem before? (And, > ideally, came up with a really neat solution...) Try to use TransactionTestCase instead of TestCase (and don't use in-memory SQLite datebase). -- Kirill Spitsin -- 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.
