Hi,
This has been sitting in my flag'd inbox for some time. Sorry for the late
reply.
> This:
>
> gremlin> t = g.V(1).outE().group().by(label).by(inV());null
> ==>null
> gremlin> t.next()
> ==>created=v[3]
> ==>knows=v[2]
>
> versus the "correct" answer of:
>
> gremlin> g.V(1).outE().group().by(label).by(inV().fold()).next()
> ==>created=[v[3]]
> ==>knows=[v[2], v[4]]
The reduction in group() is called with valueTraversal.next(). If you expect
more than one answer, you should fold(). There are a couple of things going on
here:
1. There is only one valueTraversal for each key. Meaning, each input
is not evaluated separately.
2. If we always assume a fold() at the end, then we are stuck with
things like:
gremlin> g.V().group().by(label).by(count())
==>[software:2, person:4]
gremlin> g.V().group().by(label).by(count().fold())
==>[software:[2], person:[4]]
The problem with a forced "fold" is that then users have to do an unfold() to
get to their data. Given that group() is about a "key" and a "reduce," the
reduction is assumed to be a "single thing" where fold() is actually a reducing
barrier step, where that one thing is a list full of many things :).
Hope that is clear,
Marko.
http://markorodriguez.com
>
>
>
>
> On Thu, Feb 25, 2016 at 1:58 PM, Marko Rodriguez <okramma...@gmail.com>
> wrote:
>
>> Hi,
>>
>> I don't understand the question. Can you provide a simple example?
>>
>> Thanks,
>> Marko.
>>
>> http://markorodriguez.com
>>
>> On Feb 25, 2016, at 11:54 AM, Jonathan Ellithorpe <j...@cs.stanford.edu>
>> wrote:
>>
>>> Yup
>>>
>>> On Thu, Feb 25, 2016 at 10:27 AM Stephen Mallette <spmalle...@gmail.com>
>>> wrote:
>>>
>>>> so your question is: why doesn't the Traversal in the by() iterate
>>>> everything in it rather than requiring the call to fold()?
>>>>
>>>> marko, perhaps you're best suited to answer that....
>>>>
>>>> On Thu, Feb 25, 2016 at 1:17 PM, Jonathan Ellithorpe <
>> j...@cs.stanford.edu>
>>>> wrote:
>>>>
>>>>> Very helpful, thank you. The bits about how the console automatically
>>>>> iterates over the return value was very helpful.
>>>>>
>>>>> One part that was still a little unclear to me was why only next() is
>>>>> called on the inV() Traversal for the second by().
>>>>>
>>>>> "[the console] only iterates the result of a line of execution.
>>>> Therefore,
>>>>> inner Traversal instances do not get that benefit, and as such, inV()
>>>> only
>>>>> has next() called upon it pulling a single vertex from the "knows"
>> edges"
>>>>>
>>>>> That only the returned traversal gets iterated makes sense, but why
>> that
>>>>> iteration doesn't, in its course, trigger a complete iteration of inV()
>>>> is
>>>>> unclear to me.
>>>>>
>>>>> I just started using the gremlin console yesterday so this is all new
>> to
>>>> me
>>>>> :)
>>>>>
>>>>> Jonathan
>>>>>
>>>>> On Wed, Feb 24, 2016 at 12:27 PM Kelvin Lawrence <
>>>>> kelvin.r.lawre...@gmail.com> wrote:
>>>>>
>>>>>> Thanks for putting this together. I recall we had some good exchanges
>>>>> last
>>>>>> year about the good ole console!
>>>>>>
>>>>>>
>>>>>> Kelvin
>>>>>>
>>>>>>
>>>>>> On Tuesday, February 16, 2016 at 8:13:14 AM UTC-6, Stephen Mallette
>>>>> wrote:
>>>>>>>
>>>>>>> We answer a lot of questions on the user mailing list about the
>>>> Gremlin
>>>>>>> Console and there are many themes of usage that seem to come up time
>>>> and
>>>>>>> time again. I figured that these themes would make a good addition
>>>> as a
>>>>>>> tutorial.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>
>> http://tinkerpop.apache.org/docs/3.1.1-incubating/tutorials/the-gremlin-console/
>>>>>>>
>>>>>>> I hope you all enjoy this more in-depth look at such an important
>> tool
>>>>> of
>>>>>>> the TinkerPop stack.
>>>>>>>
>>>>>>> Stephen
>>>>>>>
>>>>>>
>>>>>
>>>>
>>
>>
