> 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+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
No comments:
Post a Comment