couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Parkin <>
Subject Re: Restricting user interactions to a single document -- was [VOTE] Apache CouchDB 0.9.0 release
Date Thu, 26 Mar 2009 17:00:22 GMT
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?



View raw message