Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of nslater@tumbolia.org
 designates 209.85.215.52 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAKmKYaATTfhArhG7UQWu4srgZTDYc7rXQ5VJpBbM1ECXvyVDRg@mail.gmail.com>
References: 
 <CA+Y+447y6kT_kSz-jan89btUG02M=RDpEiKGjJ2gq_p2afTyrQ@mail.gmail.com>
	<CAJNb-9p-AY7n5Qhavis721KHg0yn2y5J0d9jMWN7_VRwWuWmAQ@mail.gmail.com>
	<CAN-3CB+qW-bofvg2hLAmFSnsWaqZBZ2GwiKsztJ=_MDmckk=iw@mail.gmail.com>
	<CABvT1DF1cqxOiHuJtGe11187GHzA47_OW=_pCN+0F5o_7FGEAQ@mail.gmail.com>
	<CAKmKYaCLpPyM6+Vt72KNEdJ_x=jXhUYQfWe7E-1UYfkPSh6fdg@mail.gmail.com>
	<CABvT1DF0SF3od+tq9Fw6982D5OM8RBiUOd_nDQh9CyQx2XS98w@mail.gmail.com>
	<CAKmKYaB8N0FEDEsGpUGVmj6kD6hStuKyiMxyTT+WHo9y1=UseQ@mail.gmail.com>
	<CABvT1DH0-z4_ToQjzmJFUXy-8xPyXg3zn0y32ZvCS4qRT+EanQ@mail.gmail.com>
	<CAKmKYaATTfhArhG7UQWu4srgZTDYc7rXQ5VJpBbM1ECXvyVDRg@mail.gmail.com>
Date: Fri, 11 May 2012 14:37:12 +0100
Message-ID: 
 <CA+Y+446+AA2X5rXVd15_A=Q7rTCF3D5qyijS4BTLN2=fXOSJtA@mail.gmail.com>
Subject: Re: Post-mortem
From: Noah Slater <nslater@tumbolia.org>
To: dev@couchdb.apache.org
Content-Type: multipart/alternative; boundary=bcaec550ace671070f04bfc2d508

--bcaec550ace671070f04bfc2d508
Content-Type: text/plain; charset=ISO-8859-1

More comments here:

http://news.ycombinator.com/item?id=3954596

Not sure how useful they are...

(Not caught up with the thread yet, sorry!)

On Fri, May 11, 2012 at 2:34 PM, Dirkjan Ochtman <dirkjan@ochtman.nl> wrote:

> On Fri, May 11, 2012 at 3:25 PM, Robert Newson <rnewson@apache.org> wrote:
> > We're veering off-topic here, but there are several remaining issues.
> > First is that the view file is at some update_seq relative to the
> > database file. Being at update_seq N for a view means it has all the
> > changes up to and including N, but nothing after N, so while those
> > updates could be processed in parallel, they'd have to be applied to
> > the view process and view file in order.
>
> Yeah, you'd have to serialize and buffer when writing to disk again.
>
> > Secondly, and more
> > importantly, is how to handle rows that, for whatever reason, cause an
> > exception when evaluated in the function (e.g, the common case where
> > there's an undefined property and no guard clause). If the order is
> > not determined, then two database, with the same data and same view
> > code, will have different view results for the same input.
>
> I'm actually not clear on what happens with erroring view functions.
> Does it just stop processing any further document revisions?
>
> In any case, it seems okayish to do have the document updates be in a
> defined ordering but parallellize execution of the view function, then
> serialize back into document order when the results come back, doing a
> little buffering if the results aren't in order.
>
> Cheers,
>
> Dirkjan
>

--bcaec550ace671070f04bfc2d508--