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)
