[
https://issues.apache.org/jira/browse/TINKERPOP-2399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17178236#comment-17178236
]
Stephen Mallette commented on TINKERPOP-2399:
---------------------------------------------
Perhaps this issue has some relation to TINKERPOP-1529 - I'd agree that we
could say it's "expected" but agree that it could be confusing. Sometimes
Gremlin adds a bit too much magic. This general issue seems to also raise
itself in trying to make sense of BFS vs DFS with Gremlin. I'm not sure that I
have a specific course of action to propose just yet, but obviously happy to
hear suggestions on the matter while I think this one through.
> 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
> Priority: Minor
>
> Sorry if this was already discussed elsewhere.
> An example query:
> {noformat}
> g.V("1", "2", "3").aggregate(Scope.local,
> "agg").both().where(P.without("agg")){noformat}
> Please imagine a graph as *v["1"] > v["2"] -> v["3"] -> v["4"]*
> 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, hence they are not seen in the result.
> 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. It may
> not be only Store step's issue but local(aggregate) is affected too.
> 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 the logic around Barrier and LazyBarrierStrategy but the user
> may not need to recognize such context especially when then Barrier step is
> not explicitly specified by them.
> Please let me know how do you think. Thanks !
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
