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