2011/4/7 Stephan Hagemann <stephan.hagem...@googlemail.com>:
> 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.
Oh, so if any node in the path has been returned in any other path
before if (except the start node) then exclude it? That's the first
time I've heard that requirement. Love the fact that you sent a
picture, guys :)
So what about:
int hitCount = 0;
for ( Path path : ...traverse(...) ) {
if ( unique( path ) ) {
if ( hitCount++ >= 50 )
break;
// handle the path
}
}
...or wrap the Iterable<Path> from traverse in:
new FilteringIterable<Path>(...traverse(...), new Predicate<Path>() {
public boolean accept( Path path ) {
return unique( path );
}
} );
and only iterate max 50 of those. Write the unique() method however
you'd like... maybe just with a Set<Node> with all the nodes except
the start/end nodes and add all those nodes from each path and if that
set had any of those nodes then don't consider it unique.
>
> 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
>>
>
> _______________________________________________
> 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
