[jira] [Updated] (TINKERPOP-1164) ReducingBarriersSteps should use ComputerMemory, not MapReduce.

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

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

Marko A. Rodriguez updated TINKERPOP-1164:
------------------------------------------
    Fix Version/s: 3.2.0-incubating

> ReducingBarriersSteps should use ComputerMemory, not MapReduce.
> ---------------------------------------------------------------
>
>                 Key: TINKERPOP-1164
>                 URL: https://issues.apache.org/jira/browse/TINKERPOP-1164
>             Project: TinkerPop
>          Issue Type: Improvement
>          Components: process
>    Affects Versions: 3.1.0-incubating
>            Reporter: Marko A. Rodriguez
>             Fix For: 3.2.0-incubating
>
>
> This just hit me like a ton of bricks. Check this:
> {code}
> g.V().count()
> {code}
> That is:
> {code}
> TraversalVertexProgram + CountMapReduce
> {code}
> Thats stupid. Just use the "reduction" aspects of {{Memory}}. Replace {{CountMapReduce}} with:
> {code}
> memory.incr("~reducing", traverser.bulk())
> {code}
> Thats it. Likewise for all the other reducing barriers! Now, not only do we don't have to do a {{MapReduce}} job, we don't even have to break out of the {{TraversalVertexProgram}} (no more "No mid-barrier steps."). Why? Well, because its in memory, its computed on that iteration and then accessible!
> {code}
> g.V().group().by('lang').select('java').values("name")
> {code}
> That would be one TraversalVertexProgram!
> .....................why do we even have MapReduce.......................... is Memory all we really need. Crazy.............................................. thats craZy talk................................. but still, think about it.



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