couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joan Touzet <>
Subject Re: Union functions
Date Mon, 22 Sep 2014 18:08:23 GMT
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...


----- Original Message -----
From: "Hector Sanjuan" <>
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

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.

From: Stanley Iriele <>
Sent: Monday, September 22, 2014 09:08
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