Martin Häusler created TINKERPOP-3128:
-----------------------------------------

             Summary: where(without("sideEffectKey")) may depend on iteration 
order
                 Key: TINKERPOP-3128
                 URL: https://issues.apache.org/jira/browse/TINKERPOP-3128
             Project: TinkerPop
          Issue Type: Bug
            Reporter: Martin Häusler


Today I had my first use case for `where(without("sideEffectKey"))`. To my 
surprise, this step did not behave like a barrier, i.e. it did not "wait" until 
the side effect was fully evaluated.

Here's the general structure of my query:

 
{code:java}
g.traversal().V()
    .has("name", P.contains("foo"))
    .sideEffect(
        ... complex navigation ... 
        aggregate("key")
    )
   .where(without("key")){code}
 

 

The issue here is that the where(without("key")) does not enforce that the side 
effect "key" is evaluated on ALL input vertices before it checks the "without" 
clause. This leads to cases where a vertex may "slip through" the "where" step 
even though it *later* gets added to the "key" side effect.

 

In all examples in the docs, this is not an issue because they don't use 
"sideEffect". They use "aggregate" directly, and since it's part of the 
traverser path, it is always evaluated for each vertex before 
"where(without(...))" is hit.

 

The workaround to fix this is to use an explicit "barrier()" step, like so:

 
{code:java}
g.traversal().V()
    .has("name", P.contains("foo"))
    .sideEffect(
        ... complex navigation ... 
        aggregate("key")
    )
   .barrier()                 // this one
   .where(without("key"))
{code}
 

This forces gremlin to iterate through all input vertices, and they all hit the 
side effect, *before* the "where" is reached. Therefore, the side effect 
aggregation is complete and everything is fine.

 

I find this behavior somewhat surprising. If it is intended, please at the very 
least mention this in the docs. This was pretty hard to debug.

 

Also, on a side note, I found it a little irritating that we're reusing the 
"without" predicate here which usually refers to a property value, and now all 
of a sudden refers to a side effect key. Maybe "withoutSideEffectKey(...)" or 
something more explicit would be better here.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to