couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Anderson <>
Subject Re: struggling with couchdb in production
Date Thu, 28 May 2009 15:14:15 GMT
On Thu, May 28, 2009 at 7:33 AM, Damien Katz <> wrote:
> On May 28, 2009, at 10:19 AM, Brian Candler wrote:
>>> You can use [open_]revs=all to open all the conflicts (deleted conflicts
>>> too)
>> Ah, open_revs=all is new to me - it works fine, although knowing about
>> deleted revisions isn't of particular interest. What I want is all live
>> (current) conflicting versions.
>> It seems to me that this is something that Amazon Dynamo got right:
>> * A GET gives you all "live" versions of a document, plus an opaque
>>  context
>> * A PUT of an updated document (which includes this context object)
>>  replaces the corresponding set of old versions with this one
>> * A PUT never fails, but may introduce conflicting versions
>> This is both simple and powerful, and dealing with conflicts would then
>> become pretty pretty easy. As a side benefit: you would no longer need an
>> API to fetch an item by _rev, which would make it less likely that people
>> would confuse CouchDB with an RCS :-)
>> There is only one reason I can see that CouchDB picks a "preferred"
>> version
>> from amongst the conflicts, and that is for the benefit of views. However,
>> even that problem goes away if you just pass *all* versions of a document
>> to
>> the map function.
>>  function(docs) { ... }
>> The map function may then choose to:
>> - emit keys corresponding to docs[0] only (= current behaviour)
>> - emit keys corresponding to all docs
>> - perform some application-specific view merging
>> As long as the conflicting versions of the doc are returned in a
>> deterministic order, then both clients and views *could* choose to work in
>> the current way (by just picking the first version and ignoring the
>> others),
>> but they would be encouraged to highlight and/or resolve the conflicts at
>> the earliest opportunity.
>>> Also, bulk document retrieval via POST where the post body specifies
>>> the docs and revisions is something we'd like to see added to the
>>> front end too.
>> I think this is adding more complexity to the API. When would you really
>> want to get a specific rev or set of revs, rather than *all* live
>> conflicting revs?
>>> Patches welcome, I and others in community will be glad to help you.
>> I suspect that what I'm suggesting is too radical to stand much chance of
>> being merged :-( The path of least resistance, for now, is to avoid all
>> replication other than master->slave.
> Doesn't sound too radical at all. I'd like to see how well it works in
> practice.

I agree with Damien here. What you're suggesting doesn't sound like a
departure from the way CouchDB operates, just a variation or
refinement. We try to treat conflicts as a normal state. Currently we
also make it easy to ignore conflicts if your application is naive.
These changes would make it harder to be naive, which raises the bar
for entry but also ensures applications are capable of handling multi
master replication.


Chris Anderson

View raw message