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 joant@lrtw.org designates
 204.11.51.157 as permitted sender)
Date: Mon, 22 Sep 2014 22:13:02 -0400 (EDT)
From: Joan Touzet <wohali@apache.org>
Reply-To: Joan Touzet <wohali@apache.org>
To: user@couchdb.apache.org
Message-ID: <12961980.203.1411438386186.JavaMail.Joan@RITA>
In-Reply-To: <893B79D1-8F7E-491E-8992-A1AD254B3CF0@apache.org>
Subject: Re: Union functions
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

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" <rnewson@apache.org>
To: user@couchdb.apache.org
Cc: "Joan Touzet" <wohali@apache.org>
Sent: Monday, September 22, 2014 3:55:29 PM
Subject: Re: Union functions


Allowing programmatic control over which revision "wins" is fine (as long a=
s it=E2=80=99s 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=E2=80=99ve configured a read_resolve function. We co=
uld 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=3D true that his. Coded and specifie=
d by
> the end user is a totally different ask... And I believe would help couch=
db
> 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:
>=20
>> 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.
>>=20
>> I encourage you to dig through the archives and to understand why this i=
s
>> a non-trivial problem with some unsolveable constraints...
>>=20
>> -Joan
>>=20
>> ----- 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
>>=20
>> I would also like this feature (providing function is a fashion similar =
to
>> views would be nice).
>>=20
>> A couple of weeks ago I proposed adding a feature to autoresolve conflic=
ts
>> 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.
>>=20
>> H
>> ________________________________________
>> From: Stanley Iriele <siriele2x3@gmail.com>
>> Sent: Monday, September 22, 2014 09:08
>> To: user@couchdb.apache.org
>> Subject: Re: Union functions
>>=20
>> Hey...thanks for your response. Somewhere in the mix I mentioned vector
>> clocks being returned as well. You shouldn't need the ancestor doc...jus=
t
>> what it holds as a collision. Your function should be able to given 2 do=
cs
>> and a vector clocks be able to resolve the conflict.
>>=20
>> 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 =
to
>> resolve it before it makes it to the show function or is returned.
>>=20
>> 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.=
fr> wrote:
>>=20
>>>>>> 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
>>>=20
>>>=20
>>> Err... Shouldn't we need the common ancestor document too?
>>>=20
>>> 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).
>>>=20
>>> We need the ancestor document to know that his "code" was deleted and
>> that
>>> "James Bond" is the right name.
>>>=20
>>>=20
>>> Regards,
>>>=20
>>> Aur=C3=A9lien
>>>=20
>>>=20
>>=20