My point is that group().by('key').by('value/reduce') seems kind of weird
anyway. The equivalent sql would be "select 'value/reduce' ... group by
'key' ".A few alternative options: g.V().group().by(keyTraversal).mapValues(valueTraversal) //As Marko pointed out this doesn't address the old GroupStep deprecation g.V().group(keyTraversal).mapValues(valueTraversal) // group() is @Deprecated g.V().group(valueTraversal).by(keyTraversal) // group() is @Deprecated g.V().group(keyTraversal, valueTraversal) // group() is @Deprecated On Wed, 7 Oct 2015 at 01:42 Marko Rodriguez <[email protected]> wrote: > Uh…. First select() is already taken and by() is always a by()-modulator…… > :/ Even with that, we still can't fix the backwards compatibility issue as > we can't deprecate out the second by(). How do you say "if the second by() > is applied, its Deprecated?" Perhaps Logger.WARN or something.. Dunno, > sorta odd. > > Marko. > > http://markorodriguez.com > > On Oct 6, 2015, at 3:26 PM, Ran Magen <[email protected]> wrote: > > > How about changing the second 'by' to a more indicative name (could > > 'select' work?)? > > > > That way we could improve on the name (which always had me confused), and > > leave the second+third 'by's as an indication to use the old > > implementation... > > > > On יום ד׳, 7 באוק׳ 2015 at 0:18 Marko Rodriguez <[email protected]> > > wrote: > > > >> Hello everyone (and the NSA -- Kuppitz did it), > >> > >> This is regarding this ticket: > >> https://issues.apache.org/jira/browse/TINKERPOP3-866 > >> > >> In group_step_2/ branch we have a new implementation of GroupStep. Here > is > >> an example: > >> > >> g.V.group.by('name').by(outE.weight).by(max()) // old way > >> g.V.group.by('name').by(outE.weight.max()) // new way > >> > >> What is the difference, there is only two by()-modulators that can be > >> passed to group(): keyTraversal and valueTraversal. What happened to > >> reduceTraversal? Well, valueTraversal is that. If you want to reduce on > >> your values, well, add a reducing barrier step -- e.g. max, min, sum, > >> count, fold, mean, etc. In the old way, we would put all your values > into a > >> Collection<V> and then when the step was complete, we would feed those > into > >> the reduceTraversal. Now -- we can dynamically reduce on the fly. This > will > >> greatly improve speed and memory usage as we don't have to create a big > old > >> Collection<V> and instead, can reduce as new traversers are fed into > >> valueTraversal. > >> > >> So this is great and no would object. What sucks is that this is NOT > >> backwards compatible. What Stephen and I came up with (in the ticket) > is to > >> make: > >> > >> > >> > https://github.com/apache/incubator-tinkerpop/blob/group_step_2/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/dsl/graph/GraphTraversal.java#L637-L639 > >> > >> This new step groupV3d0() is a deprecated step that is what the "old > way" > >> was. Note the naming convention that Stephen used for Kryo is now used > here > >> -- V3d0 (version 3<dot>0). Thus, for users moving forward, they will > have > >> to do a "replace all" on their queries and rename "group()" to > >> "groupV3d0()". Then slowly, over time, convert their traversal to use > the > >> new group() step and its respective semantics. > >> > >> Note that in the past we have been able to do backwards compatibility > via > >> having the new step (e.g. AddVertexStep) simulate the behavior of the > old > >> step and have respective @Deprecates in there to say that particular > >> GraphTraversal methods will go away. However, in this situation, the > best > >> we can do is groupV3d0(). > >> > >> Anywho. That is that. If people have any better ideas on how to solve > this > >> backwards compatibility issue, I'm all (deaf) ears. > >> > >> Thanks, > >> Marko. > >> > >> http://markorodriguez.com > >> > >> > >
