[jira] [Closed] (TINKERPOP-1741) GroupStep's on-the-fly reducer is a bit screwy

["Marko A. Rodriguez (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/TINKERPOP-1741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marko A. Rodriguez closed TINKERPOP-1741.
-----------------------------------------
    Resolution: Invalid

You can't {{select('a')}}. You have to {{cap('a')}}. This is because {{GroupStep}} requires a "on completion" computation.

https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/step/sideEffect/GroupSideEffectStep.java#L146-L149

When does that get called?

https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/step/sideEffect/SideEffectCapStep.java#L97

Why is it like this? When should reduction happen? {{select()}} just grabs the side-effect and if it hasn't been reduced (because it might be reduced laster), then thats that. Why not have it reduced at {{group('a')}} -- nope, you can't cause you typically use side-effects repeatedly (e.g. in a {{repeat()}}). If you wanted it reduced after {{group('a')}}, you would use {{group().store('a')}}. Thus, the only step that we have the forces reduction on a side-effect is {{cap()}}.

> GroupStep's on-the-fly reducer is a bit screwy 
> -----------------------------------------------
>
>                 Key: TINKERPOP-1741
>                 URL: https://issues.apache.org/jira/browse/TINKERPOP-1741
>             Project: TinkerPop
>          Issue Type: Bug
>          Components: process
>    Affects Versions: 3.2.5
>            Reporter: Daniel Kuppitz
>            Assignee: Marko A. Rodriguez
>
> Without {{dedup():}}
> {noformat}
> gremlin> g.V().both().has("age").group("a").by("age").by(values("name").fold()).barrier().select("a").limit(1)
> ==>[32:[josh,josh,josh],35:[peter],27:[vadas],29:[marko,marko,marko]]
> {noformat}
> With {{dedup()}}:
> {noformat}
> gremlin> g.V().both().has("age").group("a").by("age").by(values("name").dedup().fold()).barrier().select("a").limit(1)
> ==>[32:[josh:josh],35:[peter:peter],27:[vadas:vadas],29:[marko:marko]]
> {noformat}
> Why do the values end up being maps? That's pretty unexpected.
> As a workaround we can do this:
> {noformat}
> gremlin> g.withSideEffect("a", [:].withDefault {[] as Set}).V().both().has("age").group("a").by("age").by(values("name").fold()).barrier().select("a").limit(1)
> ==>[27:[vadas],32:[josh],29:[marko],35:[peter]]
> {noformat}
> Also note, that {{cap()}} behaves correctly, even though we're using {{dedup()}}:
> {noformat}
> gremlin> g.V().both().has("age").group("a").by("age").by(values("name").dedup().fold()).barrier().cap("a")
> ==>[32:[josh],35:[peter],27:[vadas],29:[marko]]
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)