[
https://issues.apache.org/jira/browse/TINKERPOP-3128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cole Greer updated TINKERPOP-3128:
----------------------------------
Component/s: process
> 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
> Components: process
> 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 unidirectional 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)
