XXXGraphStepStrategy heads up -- TinkerPop 3.2.3.

[Marko Rodriguez <ma...@datastax.com>]

Hey,

So, TinkerPop 3.2.3 has LazyBarrierStrategy included as a default strategy. LazyBarrierStrategy walks a traversal and looks for flatMaps (out(), in(), both(), V(), values(), etc.) and adds “lazy barriers” to dam up the stream so as to increase the probability of bulking the traversers. One of the side-effects is that:

g.V().out().V().has(a)

is compiled to:

g.V().out().barrier().V().barrier().has(a)

Given that LazyBarrierStrategy is an OptimizationStrategy, it comes BEFORE vendor-specific ProviderOptimizationStrategies. Thus, if your XXXGraphStepStrategy simply walks from the second V() looking for has()-only, it will not be able to pull in the has() cause the barrier() blocks it. Please see what TinkerGraphStepStrategy looks like and how it acknowledges NoOpBarrierSteps (i.e. barrier()) skipping over them and “left”-propagating labels to the previous step.

	https://github.com/apache/tinkerpop/blob/master/tinkergraph-gremlin/src/main/java/org/apache/tinkerpop/gremlin/tinkergraph/process/traversal/strategy/optimization/TinkerGraphStepStrategy.java <https://github.com/apache/tinkerpop/blob/master/tinkergraph-gremlin/src/main/java/org/apache/tinkerpop/gremlin/tinkergraph/process/traversal/strategy/optimization/TinkerGraphStepStrategy.java>

Finally, you can see why a mid-V().barrier() is important as you are DEFINITELY going to get bulking so this is a crucial barrier() inclusion. It just make provider strategies a bit more complex. I’ve added this information to the upgrade.asciidocs.

Take care,
Marko.

http://markorodriguez <http://markorodriguez/>.com