couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Samuel Newson <rnew...@apache.org>
Subject Re: Union functions
Date Mon, 22 Sep 2014 19:55:29 GMT

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

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.

B.

On 22 Sep 2014, at 19:55, Stanley Iriele <siriele2x3@gmail.com> 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" <wohali@apache.org> 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" <hector.sanjuan@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 <siriele2x3@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.benel@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
>>> 
>>> 
>> 


Mime
View raw message