OK. solved. The problem was that I did something like this:
class MyModel(models.Model): field = ....#this field is marked as unique and then in tests: sid = transaction.savepoint() ml1 = MyModel(field = 'a') ml1.save() m2 = MyModel(field = 'b') self.assertRaises(IntegrityError, m2.save) tranasction.avepoint_rollback(sid) and that was case where I had problem. When I moved savepoint after m1 was create - then it is ok. Best Regards, Luke On 23 Mar, 13:16, LD <l.dzied...@gmail.com> wrote: > Thanks for response, > > savepoint api looks nice and in fact it did the thing for some tests. > But for some other I still got the same error - looks strange since > tests are trying to do simmilar logic. > > I thought that problem was in some logic in test setUp, but again in > both test cases there is setUp and they look simmilar as well. > > I also found that running single test is OK (manage.py test app > TestCase.test_name), but running whole test case (manage.py test app > TestCase) leads to error. > > Do you have any ideas? And once again thanks for response > Luke > > On 21 Mar, 02:00, Malcolm Tredinnick <malc...@pointy-stick.com> wrote: > > > On Fri, 2009-03-20 at 16:26 -0700, LD wrote: > > > Hi, > > > > Today I enforced strange situation, hope it is strange only for me nad > > > you will quickly tell me what stupidness I am doing. > > > > Well, today I have switched from sqlite to postgre. Everything was > > > perfect since I've tried to run set of unit tests for my project. > > > > Every time my tests deals with situation where IntegrityError is > > > expected test execution is stopped with error: > > > Error: Database test_my_project couldn't be flushed. Possible reasons: > > > * The database isn't running or isn't configured correctly. > > > * At least one of the expected database tables doesn't exist. > > > * The SQL was invalid. > > > Hint: Look at the output of 'django-admin.py sqlflush'. That's the > > > SQL this command wasn't able to ru > > > The full error: current transaction is aborted, commands ignored > > > until end of transaction block > > > > When I look into postgre logs I can see that db tried to do operation > > > that I was expected. I don't know why with sqlite IntegrityErrors > > > where raised normally and with postgre thet are not. > > > The issue is that PostgreSQL wants you to explicitly clean up the > > transaction that is open after an error like this occurs. SQLite doens't > > have transactions for normal operations (it does have transaction-like > > behaviour for writes, but it's not quite the same thing), which is why > > you didn't see it there. > > > Secondly, Django runs the whole test suite inside a bunch of large > > transactions. We clean up at the end of each test by rolling back the > > transaction. > > > If you're intentionally causing IntegrityErrors in your tests -- which > > isn't a bad things at all -- you just have to do a little preparation. > > The simplest solution is to use savepoints. Your tests will still run > > across all database backends, since Django provides "do nothing" > > implementations for backends that don't care about this (those where > > transactions aren't supported or aren't visible to every cursor -- > > technical details you don't have to worry about). The only slight > > problem is PostgreSQL prior to 8.0 (the 7.x didn't support savepoints). > > > Right now, savepoint handling isn't documented, mostly because I was > > waiting to check that the API didn't suck. Also, I'm not really sure > > what to do about the PostgreSQL 7.x situation, since we still nominally > > support that (there are existing non-end-of-lifed production-worthy > > distributions that use it). > > > However, to see how to use them in tests, have a look at, for example, > > django/tests/modeltests/force_insert_update/models.py. There are a few > > tests in there where we are trying to force an IntegrityError. > > > If you're using unittests, rather than doctests, the same logic still > > applies. You set up a savepoint before starting and clean it up > > afterwards. > > > Regards, > > Malcolm --~--~---------~--~----~------------~-------~--~----~ 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
