On Thu, Feb 5, 2015 at 10:53 AM, Carl Meyer <[email protected]> wrote: > 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.
I thought it was not in 1.5 because I went to https://docs.djangoproject.com/en/1.5/topics/testing/tools/#transactiontestcase and got a 404. >> 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, Why do you say that? I recently added the temp table for performance. I have a query that was taking over an hour. When I broke it into 2 queries using a temp table it then ran in 10 seconds. If I've introduced something bad in my app, I'd really like to know about that. > 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? A tearDown() method would be run after the test, right? I am sending multiple requests within one test. Thanks! -larry -- 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/CACwCsY6vpCE3Pmhq4V-tOFwHPFAbNNzYRA_1uM5iiSMzCLyCzw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
