couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joan Touzet <>
Subject Re: Union functions
Date Tue, 23 Sep 2014 02:13:02 GMT
I understand now - thanks for being patient with me. I do like the idea of
a read_resolve function, and it does indeed fit well with the "never
pick a winner" approach.


----- Original Message -----
From: "Robert Samuel Newson" <>
Cc: "Joan Touzet" <>
Sent: Monday, September 22, 2014 3:55:29 PM
Subject: Re: Union functions

Allowing programmatic control over which revision "wins" is fine (as long as it’s a true

A separate proposal was to get out of the game of choosing a winner at all. That is, couchdb
would present all leaf revisions by default, thus forcing clients to handle this.

These two ideas play nicely together. A future couchdb would show all leaf revisions *unless*
you’ve configured a read_resolve function. We could then extend that to have several built-in
read_resolve functions, like we do for reduce functions today.


On 22 Sep 2014, at 19:55, Stanley Iriele <> wrote:

> I remember that discussion... Asking the database to auto resolve is an
> intractable problem for a distributed system... But providing a function
> that executes on read when conflicts= true that his. Coded and specified by
> the end user is a totally different ask... And I believe would help couchdb
> instead of forcing the developer to pull out the docs and run the merge
> them selves... It could return in a header...the deleted revisions that
> lost or something...who knows... Bit that's the jist
> On Sep 22, 2014 11:16 AM, "Joan Touzet" <> wrote:
>> All, this has been discussed in a previous thread on the mailing list a
>> couple of weeks ago. Some serious concerns were raised - especially how
>> this works with replication and in clusters, where race conditions can
>> occur.
>> I encourage you to dig through the archives and to understand why this is
>> a non-trivial problem with some unsolveable constraints...
>> -Joan
>> ----- Original Message -----
>> From: "Hector Sanjuan" <>
>> To:
>> Sent: Monday, September 22, 2014 5:37:12 AM
>> Subject: Re: Union functions
>> I would also like this feature (providing function is a fashion similar to
>> views would be nice).
>> A couple of weeks ago I proposed adding a feature to autoresolve conflicts
>> by just picking the winning revision and discarding the old... and this is
>> basicly the generalization of it. Instead of saving conflicted revisions,
>> just apply a user's provided function and save whatever comes out of it.
>> H
>> ________________________________________
>> From: Stanley Iriele <>
>> Sent: Monday, September 22, 2014 09:08
>> To:
>> Subject: Re: Union functions
>> Hey...thanks for your response. Somewhere in the mix I mentioned vector
>> clocks being returned as well. You shouldn't need the ancestor doc...just
>> what it holds as a collision. Your function should be able to given 2 docs
>> and a vector clocks be able to resolve the conflict.
>> This can take many angles and forms but the idea is ...either have this
>> function run when faced with collisions on write... Or...on read... With a
>> query of conflicts = true..have a union function specified in the URL to
>> resolve it before it makes it to the show function or is returned.
>> I am kind of surprised at the seeming lack of interest in such a thing.
>> Riak supposedly got something like this. ...its not quite what I am
>> suggesting but its close.. for thought
>> On Sep 18, 2014 9:03 AM, "Aurélien Bénel" <> wrote:
>>>>>> Couchdb is an ap system... And stores the result of both docs during
>>> a conflict.  We have  update functions as a way to do incremental
>> updates.
>>> And show functions to do a transform on a doc before sending it. Can we
>>> have union functions to resolve a conflict between 2 docs?...I
>>> Err... Shouldn't we need the common ancestor document too?
>>> Let's suppose that a document {"name": "Bond", code: "007"}
>>> is updated in parallel as {"name": "Bond"} (for security reasons)
>>> and as {"name": "James Bond", code: "007"} (for civility reasons).
>>> We need the ancestor document to know that his "code" was deleted and
>> that
>>> "James Bond" is the right name.
>>> Regards,
>>> Aurélien

View raw message