Oooh, you nearly tricked me into looking at HN. Bad Noah!
On 11 May 2012 14:37, Noah Slater <nsla...@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 <dirk...@ochtman.nl> wrote: > >> On Fri, May 11, 2012 at 3:25 PM, Robert Newson <rnew...@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 >>
