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
