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
