[
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)
