You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tinkerpop.apache.org by "Marko A. Rodriguez (JIRA)" <ji...@apache.org> on 2015/08/03 16:00:08 UTC

[jira] [Commented] (TINKERPOP3-781) Local aggregation should not destroy path

    [ https://issues.apache.org/jira/browse/TINKERPOP3-781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14651880#comment-14651880 ] 

Marko A. Rodriguez commented on TINKERPOP3-781:
-----------------------------------------------

Path history is always destroyed on a {{ReducingBarrierStep}} because you are going from many inputs to one output. Thus, what is the history of that one output? In Gremlin2, it was the output of the last input. However, that is random given that there is no guaranteed order to the stream. This was a nightmare to deal with in Gremlin2 so we removed it in Gremlin3.

One thing we could do is have some sort of "path reduction function." For instance, if you go from 100000 paths to 1 path, there is a way to turn those 100000 paths into a 1 path. Like reducing on the object itself (100000 objects to 1 object).

> Local aggregation should not destroy path
> -----------------------------------------
>
>                 Key: TINKERPOP3-781
>                 URL: https://issues.apache.org/jira/browse/TINKERPOP3-781
>             Project: TinkerPop 3
>          Issue Type: Improvement
>          Components: process
>            Reporter: Matt Frantz
>
> Currently, if we do an aggregating step (e.g. {{fold}}, {{groupCount}}, etc.) within the {{local}} step, we lose the path information.
> {noformat}
> gremlin> g.V(1).local(both().fold()).path()
> ==>[[v[3], v[2], v[4]]]
> {noformat}
> It would be better if the preceding portion of the path were still retained like so:
> {noformat}
> gremlin> g.V(1).local(both().fold()).path()
> ==>[v[1], [v[3], v[2], v[4]]]
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)