I feel compelled to comment here...
On 20 September 2013 09:32, Richard Ward <rich...@richard.ward.name> wrote: > > 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). > So you don't think that "one step of an atomic operation failing" is reason to fail the atomic operation? Doesn't sound intuitive to me. Django is trying to enforce the _logical_ behavior. The concept of an "atomic" operation, even outside the context of DBMSs, is pretty much the consistent throughout CS. If you are expecting the step could fail, then you should wrap it in a sub-transaction - the very reason they exist. Again, you have an atomic operation [the insert] that may fail, so you want to gracefully handle it. > 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. > I absolutely agree that Django should behave consistently in this, despite the quirks of the DBMS chosen. 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." > Always a fan of improving the clarity of the docs :) [and I blame your expectations of transactions on MySQL... who seem to delight in ignoring the sane behavior :)] -- Curtis -- 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 django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
