Hi Larry, On 02/05/2015 06:57 AM, Larry Martell wrote: > On Thu, Feb 5, 2015 at 7:29 AM, Jani Tiainen <[email protected]> wrote: >> On Tue, 3 Feb 2015 19:38:31 -0500 >> Larry Martell <[email protected]> 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 [email protected].
To post to this group, send email to [email protected].
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
