couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stanley Iriele <siriele...@gmail.com>
Subject Re: Union functions
Date Mon, 22 Sep 2014 18:55:21 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message