[
https://issues.apache.org/jira/browse/TINKERPOP-2971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17783409#comment-17783409
]
Yang Xia commented on TINKERPOP-2971:
-------------------------------------
I dug a bit into this, and these are what I understood is happening. It looks
like because group() is a barrier step, it will process the result of the by()
based on the barrier involved (which is determined by the first and only first
non-local barrier step).
Before group() puts anything into the result map, it [does a
check|https://github.com/apache/tinkerpop/blob/1e9e18d5d80ff3577c4543f24bc05083f71ace57/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/step/map/GroupStep.java#L132]
to see if the barrier produces any results. In by(out().fold()), the barrier
is fold(), and the FoldStep will return empty results (i.e. no out vertices) as
an empty list [] so that gets passed on into the result map. However in
by(out().order().fold()), the barrier step becomes order() . The
OrderGlobalStep will not return any empty results, so there is no result to be
added into the map and thus is not passed on.
I.e. no result is returned with order() but fold() will return an empty list:
{code:java}
gremlin> g.V(2).out()
gremlin> g.V(2).out().order()
gremlin> g.V(2).out().fold()
==>[]{code}
Basically the one barrier is what’s filtering the traverser from result.
The select() (or other steps) doesn’t do that because the result does not rely
on any barrier so all results are passed through.
Based on the [current
implementation|https://github.com/apache/tinkerpop/blob/1e9e18d5d80ff3577c4543f24bc05083f71ace57/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/step/Grouping.java#L66],
I think this is the expected behaviour. However, one potential change is to
use the last barrier step in the list, i.e. use FoldStep instead of
OrderGlobalStep in this example, but more investigation needs to be done to
understand the full implications of such a change on traversal execution.
> having order() before fold() omits an empty list in GroupStep's value
> traversal
> -------------------------------------------------------------------------------
>
> Key: TINKERPOP-2971
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2971
> Project: TinkerPop
> Issue Type: Bug
> Components: tinkergraph
> Affects Versions: 3.6.4
> Reporter: Norio Akagi
> Priority: Critical
>
> Using the modern graph,
> {code:java}
> gremlin> g.V().group().by().by(out().fold())
> ==>[v[1]:[v[3],v[2],v[4]],v[2]:[],v[3]:[],v[4]:[v[5],v[3]],v[5]:[],v[6]:[v[3]]]{code}
> {{out().fold()}} produces an empty list when there is no solution for
> {{out()}} in a value traversal of GroupStep. However if I put {{order()}}
> those empty lists are gone.
> {code:java}
> gremlin> g.V().group().by().by(out().order().fold())
> ==>[v[1]:[v[2],v[3],v[4]],v[4]:[v[3],v[5]],v[6]:[v[3]]]{code}
> I think this is not an expected behavior.
> I don't see the similar effect in by() itself
> {code:java}
> gremlin> g.V().as("a").select("a").by(out().fold())
> ==>[v[3],v[2],v[4]]
> ==>[]
> ==>[]
> ==>[v[5],v[3]]
> ==>[]
> ==>[v[3]]{code}
> {code:java}
> gremlin> g.V().as("a").select("a").by(out().order().fold())
> ==>[v[2],v[3],v[4]]
> ==>[]
> ==>[]
> ==>[v[3],v[5]]
> ==>[]
> ==>[v[3]]{code}
> So likely this is GroupStep specific issue. We need to investigate how this
> occurs and fix if needed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
