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:


is compiled to:


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.


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 

Take care,

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

Reply via email to