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" <hector.sanj...@here.com>
To: user@couchdb.apache.org
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 <siriele...@gmail.com>
Sent: Monday, September 22, 2014 09:08
To: user@couchdb.apache.org
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.. Anyways....food for thought
On Sep 18, 2014 9:03 AM, "Aurélien Bénel" <aurelien.be...@utt.fr> 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
>
>
