+1
I'd definitely have a hard look at it.
I'm wondering if it makes sense to first revisit davisp's refactoring. Not the
second one but the first one he recently did which was just a clean up and
simplification of the code. It may have broken something but if I recall it was
more readable than the original. You might find it a better starting point.
Regards,
Bob
On Mar 8, 2011, at 2:28 PM, Randall Leeds wrote:
> When I start hacking on COUCHDB-1076 a couple nights ago I found that the
> cleanest way I could see for allowing kp_nodes to be skipped during
> traversal was for the fold function to couch_btree:foldl to be arity 4, with
> kp_node | kv_node as the first argument.
>
> Evaluating that function for every node (instead of just kv_nodes) lets us
> return {skip, Acc} to skip whole subtrees.
> Diving back into the couch_btree code to read over Damien's patch for
> COUCHDB-1084, it hit me that ModifyFun could instead be a function that was
> called for all the actions. We wouldn't need to return the query results
> because this action function could send them back to the client as they're
> found. Then we just keep the actions list as part of the accumulator and
> query_modify collapses into a btree:foldl and we no longer need so many
> similar-looking recursive functions. Off the cuff I envision modify_node
> being exported and simplified to be non-recursive and query_modify being a
> helper function to generate a fold function that uses modify_node (or
> something like this).
>
> Is this similar to anything you've done already, Paul? Would you all be
> interested if I took a crack at doing this kind of refactor?
