[
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 already.
An example query:
{noformat}
g.V("1", "2", "3").aggregate(Scope.local,
"agg").both().where(P.without("agg")){noformat}
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. It may not be only
Store step's issue but others like 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 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 !
was:
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 !
> 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 already.
> An example query:
> {noformat}
> g.V("1", "2", "3").aggregate(Scope.local,
> "agg").both().where(P.without("agg")){noformat}
> 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. It may
> not be only Store step's issue but others like 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 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)
