Thanks for clearing that up! Then I can come back to my initial comment. If the Evaluator returns paths and we are looking for nodes (sets of nodes to be specific), we have no easy mechanism that will ensure we do not return duplicate nodes (because the paths they are extracted from are not duplicates). Again, with the example:
Retrieve a set of people P that are the direct friends of person A. P should include only those friends that are also on a path between A and another user B. I have attach an image that highlights this problem. As you can see from the attached image, querying for the paths that satisfy this proposition will lead to a duplication of node P in the result. If we deduplicate after the traversal, we can't stop the traversal when we have found the maximum number of nodes we wanted to return. That is... unless we specify more complex include/exclude/continue/prune rules in an Evaluator that takes into account the nodes that it has internally stored as returnables. Is that the way to go? On Thu, Apr 7, 2011 at 10:48, Mattias Persson <matt...@neotechnology.com>wrote: > 2011/4/7 Michael Hunger <michael.hun...@neotechnology.com>: > > I think the confusing thing here is that ReturnableEvaluator talked about > including/excluding nodes > > whereas when describing the Evaluations you spoke about > including/excluding paths. > > Oh, sorry... one major difference from the old traversal framework is > that it returns nodes. The new framework returns paths leading from > the start node up to that node. You still make include/exclude > decisions based on the current position of the traversal, just that in > the new framework you've got the full path in addition to the current > node (the end node of the path). > > > > Which of those is correct ? > > > > Cheers > > > > Michael > > > > Am 07.04.2011 um 10:40 schrieb Mattias Persson: > > > >> 2011/4/7 Stephan Hagemann <stephan.hagem...@googlemail.com>: > >>> Hi guys, > >>> > >>> Dario and I are working together on this, so let me clarify, what we > want to > >>> achieve. An example query in a friend network would be: > >>> > >>> Retrieve a set of people P that are the direct friends of person A. P > should > >>> include only those friends that are also on a path between A and > another > >>> user B. > >>> > >>> We know how to find paths, but we fail at returning nodes - let alone > sets > >>> of nodes. > >>> > >>> The old ReturnableEvaluator seemed to achieve just that: "A client hook > for > >>> evaluating whether a specific node should be returned from a > traverser.", > >>> but that is deprecated in the current milestone release. We're unable > to > >>> find the equivalent functionality with the new Traversal framework. > >> > >> ReturnableEvaluator is like controlling the INCLUDE/EXCLUDE part of an > >> evaluation > >> StopEvaluator is like controlling the CONTINUE/PRUNE part of an > evaluation > >> > >> The @Deprecated TraversalDescription#prune and #filter are also a > >> direct mapping of StopEvaluator and ReturnableEvaluator respectively. > >> Evaluator replaces those and combines them into one concept where you > >> can express the same semantics. > >> > >>> > >>> Thanks > >>> Stephan > >>> > >>> > >>> > >>> On Thu, Apr 7, 2011 at 09:35, Mattias Persson < > matt...@neotechnology.com>wrote: > >>> > >>>> Sory, I meant > >>>> > >>>> INCLUDE_AND_PRUNE > >>>> the path will be included in the result set, but the traversal > >>>> won't go further down that path, but will continue down other paths > >>>> that haven't been pruned > >>>> > >>>> > >>>> > >>>> -- > >>>> 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 > >>>> > >>> _______________________________________________ > >>> 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 > >> _______________________________________________ > >> 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 > _______________________________________________ > Neo4j mailing list > User@lists.neo4j.org > https://lists.neo4j.org/mailman/listinfo/user >
<<attachment: returning_paths_vs_nodes.jpg>>
_______________________________________________ Neo4j mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
