Thanks for the feedback, you too.
I'll take a hard look at what Paul's done and I'll start in and see if it
makes sense.
I'm aiming for less eye bleed, not more.
And as far as not changing existing usage... there's not too many places
where query_modify or add_remove are called.
And for the fold function, the convert_fun_arity can easily turn old 3-arity
functions into 4-arity funs that just ignore kp_nodes.
But, that's enough discussion. I'll take a swing at the bat when I can and
if it works, it works.
On Tue, Mar 8, 2011 at 12:11, Robert Dionne <dio...@dionne-associates.com>wrote:
> +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?
>
>
