Hi Larry, On 02/05/2015 06:57 AM, Larry Martell wrote: > On Thu, Feb 5, 2015 at 7:29 AM, Jani Tiainen <rede...@gmail.com> wrote: >> On Tue, 3 Feb 2015 19:38:31 -0500 >> Larry Martell <larry.mart...@gmail.com> wrote: >> >>> I have a django app that uses a temp table. In the real world this is >>> no issue, as each invocation of the app runs in its own MySQL session >>> so there cannot be any conflict with the temp tables. But in my tests >>> there are multiple requests sent, and apparently they are all in the >>> same session, as on the second request I get an error because the temp >>> table already exists. I tried logging out between requests, and I >>> tried creating a new Client instance for each request, but I still got >>> the error. Then I tried deleting the Client object, but I got Client >>> object has no attribute __del__. >>> >>> What I can do so that each request in a test has its own MySQL session? >> >> >> Instead of Django standard TestCase (which internally wraps all in single >> transaction and makes transactions as a no-op), you should use >> TransactionalTestCase. >> >> https://docs.djangoproject.com/en/1.7/topics/testing/tools/#transactiontestcase > > Thanks for the reply Jani. We're using 1.5 and I don't think this is > available in that version. We'll probably be moving to 1.6 soon > though, and it is there.
TransactionTestCase has been around for quite a long time (since 1.1,
IIRC). It's definitely in 1.5.
> But I'm not sure how this will be useful to
> me. The docs say "A TransactionTestCase resets the database after the
> test runs by truncating all tables." My test code is something like
> this:
>
> # load test data
> # login
> response = self.client.get('...')
> self.assertEqual(response.status_code, 200)
> # collect results
>
> response = self.client.get('...')
> self.assertEqual(response.status_code, 200)
> # collect results
>
> and so on. I need the temp table to get dropped between each get call.
> The best way to do this is if each is in its own MySQL session. Having
> the table truncated doesn't really accomplish this. I think I will
> have to modify the code to drop the temp table after it's used. I hate
> to muck with working production code to accommodate a test, but I also
> don't want the test branch to have a different code base from the
> production branch. I'll probably go with the former option.
I agree, I don't think TransactionTestCase will help with this situation.
I find the production design a bit questionable, but taking it as a
given that it meets your needs adequately and you don't want to change
it, you could also address this problem by simply dropping the temp
table in a tearDown() method, no?
Carl
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/54D39205.5090800%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: OpenPGP digital signature
