Antony Blakey wrote: > > 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?
Well the difference is I'm more interested the ability to rollback than the atomicity. The philosophical objection (AFAICT) is to the atomicity of bulk_docs. So if we can simplify the rollback that would be goal number 1 acheived.. The simplest way to do this would probably be to reinstate bulk_docs I imagine (as your comment below points out). The alternative is to create a virtual revision layer system over couch, which we're testing and writing up, but this would have interesting repurcussions (the system would probably not use couchdb's replication model as each replication is just a union and you would have to layer a new conflict system on top of couch's - I'll try to write this up soon) > > 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. > I'd be very interested - could I have a play with it? Cheers Tim
