Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of siriele2x3@gmail.com
 designates 209.85.216.53 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <19628772.99.1411409304608.JavaMail.jtouzet@jtouzet>
References: <1411378631685.99672@here.com>
	<19628772.99.1411409304608.JavaMail.jtouzet@jtouzet>
Date: Mon, 22 Sep 2014 11:55:21 -0700
Message-ID: 
 <CAPNuaCh+KOZhiv20UkiCgm-1R_OrE4D0FQxrkE-U4i2n90ZY+g@mail.gmail.com>
Subject: Re: Union functions
From: Stanley Iriele <siriele2x3@gmail.com>
To: user@couchdb.apache.org, Joan Touzet <wohali@apache.org>
Content-Type: multipart/alternative; boundary=089e014947f822cab10503abfe96

--089e014947f822cab10503abfe96
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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=3D 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 t=
o
> views would be nice).
>
> A couple of weeks ago I proposed adding a feature to autoresolve conflict=
s
> by just picking the winning revision and discarding the old... and this i=
s
> 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 doc=
s
> 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 =3D true..have a union function specified in the URL t=
o
> 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=C3=A9lien B=C3=A9nel" <aurelien.benel@utt.f=
r> wrote:
>
> > >>>  Couchdb is an ap system... And stores the result of both docs duri=
ng
> > 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=C3=A9lien
> >
> >
>

--089e014947f822cab10503abfe96--