[ 
https://issues.apache.org/jira/browse/TINKERPOP-3128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Martin Häusler updated TINKERPOP-3128:
--------------------------------------
    Description: 
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 unidirectional 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.

  was:
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.


> 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
>            Priority: Major
>
> 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 unidirectional 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