[jira] [Updated] (TINKERPOP-2399) LazyBarrierStrategy may affect the result of a query with a local aggregate step

["redtree (Jira)" <ji...@apache.org>]

     [ 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)