Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of jchris@gmail.com designates
 209.85.221.21 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:sender:in-reply-to:references:date
         :x-google-sender-auth:message-id:subject:from:to:content-type
         :content-transfer-encoding;
        b=Cx5m1ixUURYLxnd49g4vGNFPJTP8u8y3cfnA7GuHmpRpW1koHLJMb5jvxDJr/z0Em9
         Tfku0EBJMMIf23k3Is+wf3ZcGuHC42DXOyrI2c+YoNvNf75ekSy0lEade8SmYDKMo9+f
         pKatgpmpC99T6KhKGzWOPuoonSqkYKgNCMnOo=
MIME-Version: 1.0
Sender: jchris@gmail.com
In-Reply-To: <FBCA6E12-5EC5-401E-A6DB-5B055F132F9B@gmail.com>
References: <20090128153026.GA12384@uk.tiscali.com>
	 <e282921e0901290950n18a29409o2de847c1d1fb594e@mail.gmail.com>
	 <91CE1D9D-2D5A-40BA-8D20-D24559BBA0F0@apache.org>
	 <20090129210009.GC28166@uk.tiscali.com>
	 <A82BF3D2-733A-4C6E-B5E1-8E43039D140B@apache.org>
	 <06CD9F6F-D8E8-4057-8454-DE85CA4D1C87@gmail.com>
	 <e282921e0901291519r6d6cf239ya48623b1d0bca04e@mail.gmail.com>
	 <832E01A3-CD2B-4DA0-98FC-4908FE962396@gmail.com>
	 <e282921e0901292247k41dbce5bie1fe096574757560@mail.gmail.com>
	 <FBCA6E12-5EC5-401E-A6DB-5B055F132F9B@gmail.com>
Date: Fri, 30 Jan 2009 00:00:26 -0800
Message-ID: <e282921e0901300000n19c9faf1g2140b007cd0848b8@mail.gmail.com>
Subject: Re: Trouble with replication
From: Chris Anderson <jchris@apache.org>
To: user@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On Thu, Jan 29, 2009 at 10:56 PM, Antony Blakey <antony.blakey@gmail.com> wrote:
>
> Extending this to update functions means that conflict resolution is no
> longer globally deterministic, because it depends on the propagation pattern
> of the update function. Same with validation and authentication.
>
> This will only affect some use cases, but it's a very difficult problem in
> meshes.

Ahh, I didn't consider the validation function as being replicated as
well. I suppose I'm imagining that validation functions will define
the borders of applications, and thinking of these data flows as
within a particular application.

This is a straightforward consequence of the fact that design docs are
documents just like any other, which of course has so many good
effects that it's hard to find fault with the system because of edge
cases like this.

Another edge case from validation functions (which can happen even on
a single node) is that documents which have been added to a db, can be
invalidated by the addition of a validation function after they have
been saved. Having a view of all newly-invalid docs will definitely be
useful.

It seems like if you want to ensure that your system follows some of
the stricter principles you outlined, you'll have to avoid use of
(changing) validation functions in your applications. Or at least be
very thoughtful about code roll-outs.

This may be a logical fallacy, but finding an "inconsistency" like
this, encourages me that we maybe dealing with a "complete" system.
I'd rather have something powerful enough to generate inconsistencies
than something so meager that it can't.

-- 
Chris Anderson
http://jchris.mfdz.com