It can be done with the new API also. Either have an instance implementing both PruneEvaluator and Predicate<Path>. Or (as they are deprecated) just implement an Evaluator.
2010/12/27 Craig Taverner <[email protected]> > 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 > -- Mattias Persson, [[email protected]] Hacker, Neo Technology www.neotechnology.com _______________________________________________ Neo4j mailing list [email protected] https://lists.neo4j.org/mailman/listinfo/user
