[
https://issues.apache.org/jira/browse/TINKERPOP-2399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
redtree updated TINKERPOP-2399:
-------------------------------
Description:
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 !
was:
Sorry if this was already discussed already.
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 !
> 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)
