incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Kocoloski <kocol...@apache.org>
Subject Re: What happens with a document, if a conflict is not resolved?
Date Sat, 31 Oct 2009 00:37:36 GMT
On Oct 30, 2009, at 9:15 AM, Brian Candler wrote:

> On Fri, Oct 30, 2009 at 08:33:52AM +0000, Brian Candler wrote:
>> Yes, I know patches are welcome. The reason I'm not contributing  
>> code for
>> this right now is that I have higher priorities - I'm happy to keep  
>> my app
>> 409-tied while I work on other things.
>
> On the other hand, I am happy to contribute some documentation. I just
> wrote the following page, which turned out to be longer than expected:
> http://wiki.apache.org/couchdb/Replication_and_conflicts
>
> Some interesting things came out while working this through. You can  
> see an
> example Ruby script I wrote which replaces GET and PUT with multi-rev
> equivalents. I don't know of any existing client library which does  
> this,
> but once you're clear what is needed, it's quite straightforward.
>
> Then if you use this, your application can forget about all 409  
> handling,
> because you'll never see one.
>
> I think turning this into a native API would be good - even if it's  
> just
> GET ?all=true and PUT ?revs=[rev1,rev2,rev3]
>
> Regards,
>
> Brian.

I like where your head's at on this, Brian.  I should mention that it  
*is* possible to retrieve all conflict revisions of a document with  
one request:

GET /db/bob?open_revs=all

The response format is a slightly awkward Array -- I believe the first  
revision is the winning one.

[{"ok":{"_id":"bob","_rev":"1-3453545",...}},{"ok": 
{"_id":"bob","_rev":"1-23042"]

I think I'd be in favor of making the default GET include all  
conflicts, but probably in the _conflicts field so as to minimize the  
changes to the current API.  I'm not sure a multi-rev version of PUT  
is as urgent a need.  Best,

Adam


Mime
View raw message