[
https://issues.apache.org/jira/browse/TINKERPOP-3207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18033279#comment-18033279
]
ASF GitHub Bot commented on TINKERPOP-3207:
-------------------------------------------
Cole-Greer commented on PR #3254:
URL: https://github.com/apache/tinkerpop/pull/3254#issuecomment-3452272510
There appear to remain a few outstanding bugs in OLAP related to these
changes which I'm working on resolving.
> Add Barriers to GroupSideEffect, GroupCountSideEffect, TreeSideEffect, and
> Subgraph Steps
> -----------------------------------------------------------------------------------------
>
> Key: TINKERPOP-3207
> URL: https://issues.apache.org/jira/browse/TINKERPOP-3207
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
> Affects Versions: 3.7.4
> Reporter: Cole Greer
> Priority: Major
>
> The gremlin language is mostly agnostic as to if a traversal should be
> executed lazily (DFS), or eagerly (BFS). Our documentation does not specify a
> preference for either method, and most traversals will give the same results
> regardless of evaluation order.
> There are currently 5 steps which may lead to different results if evaluated
> in different orders: AggregateLocalStep, GroupSideEffectStep,
> GroupCountSideEffectStep, TreeSideEffectStep, and SubgraphStep.
> Consider the following example:
> {code:java}
> // Lazy evaluation
> gremlin> g.V().groupCount(“x”).select(“x”)
> ==>[v[1]:1]
> ==>[v[1]:1,v[2]:1]
> ==>[v[1]:1,v[2]:1,v[3]:1]
> ==>[v[1]:1,v[2]:1,v[3]:1,v[4]:1]
> ==>[v[1]:1,v[2]:1,v[3]:1,v[4]:1,v[5]:1]
> ==>[v[1]:1,v[2]:1,v[3]:1,v[4]:1,v[5]:1,v[6]:1]
> //Eager evaluation
> gremlin> g.V().groupCount(“x”).select(“x”)
> ==>[v[1]:1,v[2]:1,v[3]:1,v[4]:1,v[5]:1,v[6]:1]
> ==>[v[1]:1,v[2]:1,v[3]:1,v[4]:1,v[5]:1,v[6]:1]
> ==>[v[1]:1,v[2]:1,v[3]:1,v[4]:1,v[5]:1,v[6]:1]
> ==>[v[1]:1,v[2]:1,v[3]:1,v[4]:1,v[5]:1,v[6]:1]
> ==>[v[1]:1,v[2]:1,v[3]:1,v[4]:1,v[5]:1,v[6]:1]
> ==>[v[1]:1,v[2]:1,v[3]:1,v[4]:1,v[5]:1,v[6]:1]
> {code}
> This inconsistency can be resolved by pulling the solution from
> AggregateGlobalStep and making each of these steps LocalBarrier's. If there
> are ever cases where users need the old "one-at-a-time" accumulation, this
> will still be achievable by embedding the step inside local().
> {code:java}
> gremlin> g.V().local(groupCount("x")).select("x")
> ==>[v[1]:1]
> ==>[v[1]:1,v[2]:1]
> ==>[v[1]:1,v[2]:1,v[3]:1]
> ==>[v[1]:1,v[2]:1,v[3]:1,v[4]:1]
> ==>[v[1]:1,v[2]:1,v[3]:1,v[4]:1,v[5]:1]
> ==>[v[1]:1,v[2]:1,v[3]:1,v[4]:1,v[5]:1,v[6]:1]
> {code}
> This will ensure that all traversals will return consistent results,
> regardless of if is is run in a lazy or eager traversal engine.
> AggregateLocalStep is excluded from these changes as AggregateGlobalStep
> already implements the desired fix, and AggregateLocalStep is slated for
> removal according to the [proposal on Lazy/Eager
> evaluation|https://github.com/apache/tinkerpop/blob/2c3f31fdab535913c5a7b318e16f1c80bce57f35/docs/src/dev/future/proposal-scoping-5.asciidoc#proposed-further-simplifications].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
