Hi,
We can't go back to groupBy(), orderBy(), etc. First, by() is the style we have
adopted and for group() you have two by()s. A "key" and a "value". There are
various steps that make use of multiple by()s -- group(), path(), tree(),
select(), ...
g.V().group().by("age").by(sum())
by("age") is the key traversal.
by(sum()) is the value-reduce traversal.
Next, yes, looking at the GroupTest (Java) examples, its pretty brutal with the
<X,Y>group(). If you can figure out how to keep group() and by() and make it
work without <X,Y> that would be cool.
Looking at order(), groupCount(), aggregate(), etc. The by()-modulation doesn't
cause crazy <X,Y> declarations. Seems group() is are only burp.
Thank Michael,
Marko.
http://markorodriguez.com
On Jan 13, 2016, at 3:58 PM, Michael Pollmeier <[email protected]>
wrote:
> Ok now I understand why you did that.
>
> The problem is that you can't use the type parameters `E` from your
> GraphTraversal because you split up `group` and `by` into separate steps.
> E.g. for `g.V()` the type parameter `E` is `Vertex`, which makes sense.
> But for `g.V().group()` the type parameter `E` becomes `Map<Vertex, ???>`. So
> then the by step doesn't know that it operates on a Vertex any more and you
> have to pass `Vertex` to the `by` function.
> I.e. the developer has to specify all types rather than letting the compiler
> figure it out - e.g. in GroupTest.java:302 you had to write out the types all
> the way:
> `g.V().<String, Long>group().<Vertex>by(v -> v.<String>value("name"))`
>
> If you would have kept the groupBy step, the above would then become much
> shorter:
> `g.V().groupBy(v -> v.<String>value("name"))`
>
> Basically, the split of `group` and `by` makes the java API painful. Groovy
> doesn't care about the types so you probably didn't notice. If we care about
> the java API (I certainly do), then I would suggest to go back to `groupBy`,
> `orderBy` etc. or come up with an alternative solution.
>
> Does this make sense?
>
>
> On 01/12/2016 04:51 AM, Marko Rodriguez wrote:
>> Hi,
>>
>> I'm not sure why I did this. I suspect it could just be <U,V>. If you type
>> it like that, do you run into an compilation issues? If you get it working
>> as such and it makes sense without having to change any of the casts in the
>> test suites, please provide a PR.
>>
>> Thanks,
>> Marko.
>>
>> http://markorodriguez.com
>>
>> On Jan 10, 2016, at 3:51 PM, Michael Pollmeier
>> <[email protected]> wrote:
>>
>>> No answer on this one yet - what's a better place to ask? Should I create a
>>> jira ticket instead?
>>>
>>> On 12/21/2015 06:59 PM, Michael Pollmeier wrote:
>>>> I don't understand the types on the `by` steps that take a function
>>>> projection.
>>>>
>>>> 1) Shouldn't it be `Function<E, V>` for the function parameter in both
>>>> cases?
>>>> 2) What is the reason for constraining the function passed to the second
>>>> one to `Element`?
>>>>
>>>> without comparator:
>>>> <V> GraphTraversal<S, E> by(Function<V, Object>)
>>>>
>>>> with comparator:
>>>> <V> GraphTraversal<S, E> by(Function<Element, V>, Comparator<V>)
>>>>
>>>> (from GraphTraversal.java)
>>>>
>>>> Cheers
>>>> Michael
>>>>
>>
>>
