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
