[
https://issues.apache.org/jira/browse/TINKERPOP-1367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15372829#comment-15372829
]
Marko A. Rodriguez commented on TINKERPOP-1367:
-----------------------------------------------
Oh. Well, in that case, that is not a reducing barrier step... You need to find
ALL max paths......... hmmm...
So there are two 1.0 weight values in the Modern graph.
{code}
gremlin> g.V().outE().values('weight').order().by(decr).limit(2).path()
==>[v[1], e[8][1-knows->4], 1.0]
==>[v[4], e[10][4-created->5], 1.0]
{code}
I don't even know how to express this easily without two traversals...
{code}
gremlin>
g.V().outE().values('weight').max().as('a').V().outE().values('weight').where(eq('a')).path()
==>[1.0, v[1], e[8][1-knows->4], 1.0]
==>[1.0, v[4], e[10][4-created->5], 1.0]
{code}
Ah...we could do something like {{MaxSideEffectStep}} analogous to
{{GroupCountStep}} and {{GroupCountSideEffectStep}}. THE BELOW DOESN'T EXIST,
BUT DEMONSTRATES THE IDEA:
{code}
gremlin> g.V().outE().values('weight').max('a').barrier().where(eq('a')).path()
==>[1.0, v[1], e[8][1-knows->4], 1.0]
==>[1.0, v[4], e[10][4-created->5], 1.0]
{code}
The above can currently be done using {{sideEffect}}-step. THE BELOW DOES EXIST.
{code}
gremlin> g.withSideEffect('a',0).V().outE().values('weight').sideEffect{t ->
if(t.get() > t.sideEffects('a'))
t.sideEffects('a',t.get())}.barrier().where(eq('a')).path()
==>[v[1], e[8][1-knows->4], 1.0]
==>[v[4], e[10][4-created->5], 1.0]
{code}
Thus, you store the max value into the side-effect {{a}}. You {{barrier()}} so
you aggregate it all to get the true max (as opposed to a running max) and then
you drain the barrier and filter those values that aren't the max {{a}}. The
problem here is the {{barrier}} which makes this NOT a lazy traversal and thus,
lots of memory consumption (especially with path calculations turned on). In
this respects, we are back to the {{order().limit()}}-pattern which is also
memory intensive (unless we get {{OrderLimitStrategy}} to work with OLTP).
> Preserve path history for min() and max()
> -----------------------------------------
>
> Key: TINKERPOP-1367
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1367
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
> Affects Versions: 3.2.0-incubating
> Reporter: Jason Plurad
>
> Via https://groups.google.com/d/msg/gremlin-users/qZwsvRjw7L4/YyT-s1foBAAJ
> {noformat}
> gremlin> g.V().outE().as('e').values('weight').path()
> ==>[v[1], e[9][1-created->3], 0.4]
> ==>[v[1], e[7][1-knows->2], 0.5]
> ==>[v[1], e[8][1-knows->4], 1.0]
> ==>[v[4], e[10][4-created->5], 1.0]
> ==>[v[4], e[11][4-created->3], 0.4]
> ==>[v[6], e[12][6-created->3], 0.2]
> gremlin> g.V().outE().as('e').values('weight').max().path()
> ==>[1.0]
> {noformat}
> Currently all reducing barriers are treated the same (min, max, mean, etc.).
> But they are indeed different when it comes to path computations. Some of
> them could preserve the path history, others could not.
> For max() and min(), we could preserve the path history. In fact, in this
> respect, max() and min() would NOT be ReducingBarrierSteps, but in fact be
> some sort of "barrier" FilterStep.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
