> > 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. > ... > 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. >
In my defense... as far as I was concerned I did gracefully handle it - I caught the exception in python. If my desired outcome is: ((A or B) then C) or ((A unless IntegrityError) then C) and A and B are atomic, then I don't see the need for a sub-transaction (If the DB allows such behavior) - I'm not firing A, B and C at the database blindly, I'm reacting to what the DB tells me about each statement's execution before sending the next. Either my whole block of code is executed as I intended, or there is a rollback. If I'm sending a batch of commands to the DB I can see how MySQL's behavior will cause pain, but given that I'm always using another language to send commands one by one to the db with the ability for my code to react, I'd not previously noticed that MySQL's behavior was odd. Anyway, my point was that I think others are not unlikely to try this. If they do, its not so easy to tell what has gone wrong. I appreciate that Django can't deal with people trying really hard to break things, I just don't reckon I was trying that hard :) I'll open a ticket about the docs later today. -- 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.
