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 > > > > >
