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. 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.

-- 
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/CACwCsY5wVz5nJffYQXGiczfSN_K8wRqDBbGp2sGW%3Dt%2BLQTQ7Ww%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to