I just spent less than two hours making this change locally and everything works and it generally feels great. Now that I've tried it out myself, this way of controlling pruning/filtering feels more awesome. I'll post some examples soon so that you can feedback :)
2010/11/10 Mattias Persson <matt...@neotechnology.com> > I've also thought about it, because if you think about it... pruning is > just really there for performance issues and it may be possible to combine > filtering/pruning somehow, yes. > > 2010/11/7 Yaniv Ben Yosef <yani...@gmail.com> > > It's a personal taste, but I'm not sure I like all those permutations in >> combined values. >> Perhaps you'll consider that the evaluator would return an object with two >> enums: >> >> 1. STOP / CONTINUE >> 2. INCLUDE / EXCLUDE >> >> This will also make it easier to extend the evaluator, so if additional >> state is needed to be returned, you just add another enum and don't have >> to >> change all the existing values.. >> >> Hope this makes sense. >> --- Yaniv >> >> On Fri, Nov 5, 2010 at 8:56 PM, David Montag < >> david.mon...@neotechnology.com >> > wrote: >> >> > Hi all, >> > >> > Hopefully most of you are familiar with the traversal framework that was >> > introduced in 1.1. It's powerful and provides for reusable traversal >> > descriptions. It has some flaws though, and I would like to discuss one >> of >> > them here. >> > >> > The traversal framework has this concept of pruning, which basically is >> an >> > evaluation for each position, deciding whether or not to continue the >> > traversal down this branch. The caveat here is that when you evaluate a >> > position, you can't opt to prune before it. If you want to exclude a >> node >> > based on information from that node, filtering has to be done on top of >> the >> > pruning, with the same algorithm - once to stop the traversal, and once >> to >> > exclude the node. >> > >> > So there are actually two orthogonal concepts at work here: whether to >> stop >> > or not, and whether to include or not. What I'm proposing is to merge >> these >> > two into one evaluator. That evaluator would return one of four values: >> > >> > CONTINUE_AND_INCLUDE_NODE, >> > STOP_AND_INCLUDE_NODE, >> > STOP_AND_EXCLUDE_NODE, or >> > CONTINUE_AND_EXCLUDE_NODE. >> > >> > This would replace both the filtering and the pruning. I'm just throwing >> > this out there to see if anyone else has had the same idea. Like / >> dislike? >> > >> > -- >> > David Montag >> > Neo Technology, www.neotechnology.com >> > Cell: 650.556.4411 >> > david.mon...@neotechnology.com >> > _______________________________________________ >> > Neo4j mailing list >> > User@lists.neo4j.org >> > https://lists.neo4j.org/mailman/listinfo/user >> > >> _______________________________________________ >> Neo4j mailing list >> User@lists.neo4j.org >> https://lists.neo4j.org/mailman/listinfo/user >> > > > > -- > Mattias Persson, [matt...@neotechnology.com] > Hacker, Neo Technology > www.neotechnology.com > -- Mattias Persson, [matt...@neotechnology.com] Hacker, Neo Technology www.neotechnology.com _______________________________________________ Neo4j mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
