Thanks for the explanations. I wasn't aware that particular difference 
between PostgreSQL and MySQL (I've not done much with PostgreSQL).

Perhaps I could have been clearer in my original post: Ansii is right about 
silence... when I call my_func the transaction.atomic decorator rolls back 
the transaction and then returns, rather than (eg) rolling back the 
transaction and then raising/propagating an exception (when using MySQL).

I don't think that what I was trying to do (continue using a transaction 
after an insert failed) was too outlandish. I'm not demanding that Django 
should allow me to do it (tho that would be nice), but I can see other 
people trying to do it - especially if they are mostly used to MySQL, which 
allows it. It may not be correct, but it is (IMO) intuitive - why should a 
transaction have to be considered completely ruined just because an insert 
failed, when I expected that it may happen? (I don't need an answer to 
that, just explaining my/others thought process). If Django must enforce 
PostgreSQL style behavior, then an exception at some point telling me off 
for my bad behavior would be useful. IIUC correctly I'd get that exception 
with Django+PostgreSQL but I don't get any with Django+MySQL.

Either way I think the docs could be improved: "Wrapping atomic in a 
try/except block allows for natural handling of integrity errors" is not 
the same as "DatabaseErrors must be caught outside the atomic block". Also 
"If the block of code is successfully completed, the changes are committed 
to the database. If there is an exception, the changes are rolled back" 
implies to me that the transaction will be rolled back iff an exception 
causes the stack to unwind past transaction.atomic, but the intent is "If 
there is any DatabaseError [or any other exception raised inside a 
transaction.atomic(savepoint=False)], even if it is caught by user code, 
the changes are rolled back."

Thanks,
Richard

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to