couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Newson <rnew...@apache.org>
Subject Re: Post-mortem
Date Fri, 11 May 2012 14:34:40 GMT
Oooh, you nearly tricked me into looking at HN. Bad Noah!

On 11 May 2012 14:37, Noah Slater <nslater@tumbolia.org> wrote:
> 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
>>

Mime
View raw message