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.
-Joan ----- Original Message ----- From: "Robert Samuel Newson" <[email protected]> To: [email protected] Cc: "Joan Touzet" <[email protected]> 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 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 <[email protected]> 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" <[email protected]> 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" <[email protected]> >> To: [email protected] >> 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 <[email protected]> >> Sent: Monday, September 22, 2014 09:08 >> To: [email protected] >> 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" <[email protected]> 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 >>> >>> >>
