redtree created TINKERPOP-2399:
----------------------------------
Summary: LazyBarrierStrategy may affect the result of a query with
a local aggregate step
Key: TINKERPOP-2399
URL: https://issues.apache.org/jira/browse/TINKERPOP-2399
Project: TinkerPop
Issue Type: Bug
Components: process
Reporter: redtree
Sorry if this was already discussed already.
An example query:
{{g.V("1", "2", "3").aggregate(Scope.local,
"agg").both().where(P.without("agg"))}}
Please imagine a graph looks like *v["1"] > v["2"] -> v["3"] -> v["4"] ->
v["5"]*
The result is: v[2], v[3], and v[4]
This is because due to the nature of local scope, when both() of v["1"] (=
v["2"]) reaches to the where step, agg = v["1"] only. so v["2"] passes the
predicate. In the same way v["3"] and v["4"] are also passed.
However, if you have multiple both steps like
{noformat}
g.V("1", "2", "3").aggregate(Scope.local,
"agg").both().both().where(P.without("agg")){noformat}
You will see that when the first solution reaches to the where step, all
v["1"], v["2"] and v["3"] are already collected in agg as if the aggregate step
has the global scope.
Why ? Because here by having 2 both() steps LazyBarrierStrategy kicks in for
the first both() step and NoOpBarrierStep is inserted, then it eagerly collects
the solution from upstream. As a result, when the downstream is processed,
already all solutions are in the Aggregation sideEffect.
I am not sure if this is a bug, we might say "this is by design", but it is
felt a bit counter-intuitive from a user's perspective. Graph provider needs to
understand these logic but the user may not need to perceive such context like
Barrier especially when then Barrier step is not explicitly specified by the
user.
Please let me know how do you think. Thanks !
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
