Hi all,
I believe that I have found a bug in Django 1.0 for both Postgresql
backends, but would very much appreciate your thoughts in case I am
misunderstanding something... The test case seems clear enough that
this must have been noticed before, and there is an existing open
ticket and patch for a related problem.
I have a simple model:
================
class Test(models.Model):
data1 = models.IntegerField(unique=True)
data2 = models.IntegerField()
================
and a view using it:
================
def render(request):
a = Test()
a.data1 = 1
a.data2 = 10
a.save()
b = Test()
b.data1 = 1
b.data2 = 20
try:
b.save()
except IntegrityError:
# Expected since data1 not unique
pass
c = Test()
c.data1 = 2
c.data2 = 30
c.save()
return HttpResponse('Test')
================
All of this code is run without transaction middleware, which I
believe means that every database operation should auto-commit
individually, regardless of whether the database supports
transactions.
Correct behavior is for the view to return 'Test' and leave objects
'a' and 'c' in the database. I observe this on both MySQL with MyISAM
tables and MySQL with InnoDB tables (which supports transactions).
With Postgresql*, an internal error is raised by the line 'c.save()',
with the text 'current transaction is aborted, commands ignored until
end of transaction block'. Only object 'a' is left in the database.
I can work around the Postgresql behaviour by adding an explicit
savepoint and rollback around 'b.save()', but surely this should not
be necessary? I am operating in autocommit mode, so there should be no
transaction present. Equally, MySQL InnoDB does not require these.
I believe this boils down to the same issue as ticket [3460] - both
the psycopg1 and psycopg2 backends are using the wrong isolation
level, as a result of which the Django SQL is wrapped by psycopg
inside an implicit transaction. I have tried using the [3460] patch,
which gives me the Postgresql behaviour that I expected.
Your thoughts very much appreciated - assuming I understand the
meaning of "autocommit" this seems quite a fundamental problem.
Best regards,
Richard.
* My test is with Postgresql 8.1.4 and Psycopg2 2.0.7. However, if my
diagnosis is correct, then this will hold for all versions and also
for the Psycopg1 backend.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
