On 26/03/2009, at 6:18 AM, Tim Parkin wrote:
I don't want to have to repeat myself but *it's not about the
consistency or atomicity*. It's about being able to make two or more
changes in a single request (via a UI or API) and if the last one
fails,
being able to roll the first ones back and tell the user "Sorry,
something went wrong, would you like to try again" instead of "you
have
a partial success, how would you like to deal with it?"
In what way is that not atomicity?
I have a patch that adds/restores fail-on-conflict bulk update
behaviour (ie. your rollback requirement, but with no intermediate
state). It's 10-15 lines depending on formatting, i.e. fairly trivial,
so it should be easy to keep it on HEAD. I trigger it explicitly by
adding fail-on-conflict: true to the top level json in the bulk
request, which means that existing tests pass because the default
semantics are unpatched.
Antony Blakey
-------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
All that is required for evil to triumph is that good men do nothing.
