I'm not so familiar with the new traversal API, but I think this was pretty
easy with the old API. You create a class that implemented both the
StopEvaluator and ReturnableEvaluator interfaces, register that class for
both cases, and then that class becomes the 'Traversal Context'. Since it is
your class, it can store whatever state you want, and update that state
based on events coming from both of those interfaces. I used this 'trick' to
traverse my multi-dimensional index tree in 2009, and hopefully will update
this for the new traversal API (if possible) for the new composite index.
For the original question by Amos, the object would have some code
if(val==null){val=rel.getProperty('key');} called on any event, and then in
the stop evaluator test always that the current relation matches that
property.
So, does anyone know if this idea will work for the new traversal API? If
the new evaluators cannot be implemented as the same class instance, then
perhaps another trick is needed.
On Fri, Dec 24, 2010 at 5:09 AM, Guru GV <[email protected]> wrote:
> May be it could just be that the "Traversal Context" (in simple form
> may be just a wrapper around a HashMap) be injected into all Traversal
> Controls like expander etc. And this could be accessed as a method
> parameter or as getter() or as member variable.
>
> On Fri, Dec 24, 2010 at 9:14 AM, Guru GV <[email protected]> wrote:
> > +1,
> > I think a "Traversal Context" would be of great help. May be the
> > thoughts have to be more refined as to how the API can expose the
> > context in a intuitive manner.
> >
> > On Thu, Dec 23, 2010 at 9:57 PM, David Montag
> > <[email protected]> wrote:
> >> Hi,
> >>
> >> Mattias, your solution works because Amos' algo was a special case where
> you
> >> can verify the path simply by looking one step back. It's a smart
> solution
> >> to his problem!
> >>
> >> However, what about traversals where you have more complex calculations
> >> going on and essentially want to carry a state along with you from hop
> to
> >> hop. That state would be different for each traversal branch. Is that
> >> something the traversal API should support? Community, WDYT? (sorry for
> >> thread hijack)
> >>
> >> David
> >>
> >> On Thu, Dec 23, 2010 at 12:48 PM, Mattias Persson <
> [email protected]
> >>> wrote:
> >>
> >>> Hi, interesting traversal... so you're saying that paths like this
> could be
> >>> returned:
> >>>
> >>> (start)-B->()-A[P=1]->()-A[P=1]->()-B->(end)
> >>>
> >>> but not paths like this:
> >>>
> >>> (start)-A[P=1]->()-B->()-A[P=2]->(end)
> >>>
> >>> am I correct? There are common path algorithms in
> >>> GraphAlgoFactory<
> >>>
> http://components.neo4j.org/neo4j-graph-algo/apidocs/org/neo4j/graphalgo/GraphAlgoFactory.html
> >>> >but
> >>> they don't support an evaluator as an argument, an evaluator which
> >>> could
> >>> look like:
> >>>
> >>> {
> >>> public Evaluation evaluate( Path position )
> >>> {
> >>> Relationship rel = position.lastRelationship();
> >>> if ( rel == null || !rel.isType( MyRelTypes.A ) )
> >>> return Evaluation.INCLUDE_AND_CONTINUE;
> >>>
> >>> Object p = rel.getProperty( "P" );
> >>> Object previousP = lookBackwardsForP( position );
> >>> if ( previousP != null && !p.equals( previousP ) )
> >>> return Evaluation.EXCLUDE_AND_PRUNE;
> >>> return Evaluation.INCLUDE_AND_CONTINUE;
> >>> }
> >>>
> >>> private Object lookBackwardsForP( Path position )
> >>> {
> >>> int count = 0;
> >>> for ( Relationship rel : position.relationships() )
> >>> {
> >>> // Skip the first one
> >>> if ( count++ > 0 )
> >>> {
> >>> if ( rel.isType( MyRelTypes.A ) )
> >>> return rel.getProperty( "P" );
> >>> }
> >>> }
> >>> return null;
> >>> }
> >>> }
> >>>
> >>> You could probably create a breadth first traverser with such an
> evaluator
> >>> to get your paths. I don't know about performance since each evaluation
> >>> needs to go back one or more steps in the path, but you could try it
> out.
> >>>
> >>> 2010/12/23 Amos Ben Israel <[email protected]>
> >>>
> >>> > Hello,
> >>> >
> >>> > I'm trying to find all paths between two nodes when relations can be
> of
> >>> one
> >>> > of two types (A or B) without repeating the same node twice - so far
> >>> quite
> >>> > simple.
> >>> > the complication is that relations of type A have a property P and I
> want
> >>> > only paths where P has the same value all the way (but can have two
> >>> > different values in two different paths).
> >>> > I tried to have a variable that is reset every time the traverse
> "starts
> >>> > again from the beginning" but find it difficult to know when did this
> >>> > happen. position.length() helps when I only have relations of type A
> - it
> >>> > does not ignore relations of type B which can be on the path.
> >>> > iterating over the path at each position works but seems inefficient
> -
> >>> I'd
> >>> > like to hear ideas for a more efficient solution.
> >>> >
> >>> > Amos.
> >>> > _______________________________________________
> >>> > Neo4j mailing list
> >>> > [email protected]
> >>> > https://lists.neo4j.org/mailman/listinfo/user
> >>> >
> >>>
> >>>
> >>>
> >>> --
> >>> Mattias Persson, [[email protected]]
> >>> Hacker, Neo Technology
> >>> www.neotechnology.com
> >>> _______________________________________________
> >>> Neo4j mailing list
> >>> [email protected]
> >>> https://lists.neo4j.org/mailman/listinfo/user
> >>>
> >>
> >>
> >>
> >> --
> >> David Montag
> >> Neo Technology, www.neotechnology.com
> >> Cell: 650.556.4411
> >> [email protected]
> >> _______________________________________________
> >> Neo4j mailing list
> >> [email protected]
> >> https://lists.neo4j.org/mailman/listinfo/user
> >>
> >
> _______________________________________________
> Neo4j mailing list
> [email protected]
> https://lists.neo4j.org/mailman/listinfo/user
>
_______________________________________________
Neo4j mailing list
[email protected]
https://lists.neo4j.org/mailman/listinfo/user
