[
https://issues.apache.org/jira/browse/TINKERPOP-1113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette reassigned TINKERPOP-1113:
-------------------------------------------
Assignee: stephen mallette
> GraphComputer subclasses should support native methods
> ------------------------------------------------------
>
> Key: TINKERPOP-1113
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1113
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
> Affects Versions: 3.1.0-incubating
> Reporter: Marko A. Rodriguez
> Assignee: stephen mallette
> Priority: Major
>
> TinkerPop is all about interoperability. SparkGraphComputer and
> GiraphGraphComputer have the same "look and feel." This is great as all you
> need to do is change your reference from Spark to Giraph and BAM, your same
> code just works.
> However, there are times when we need specifics. In 3.1.0 we introduced
> {{GraphComputer.configure(String,Object)}} which allowed for
> computer-specific configurations (e.g. giraph.zookeeper.ip or
> spark.memory.shuffleFraction). Just allowing this means your code isn't THAT
> portable. I think we should take this one step further and allow:
> {code}
> SparkGraphComputer.master(String).persistContext(boolean).graphStorageLevel(StorageLevel).persistStorageLevel(StorageLevel)
> {code}
> This way, we have a clear API with typing and pre-execution checking! instead
> of what people would do now:
> {code}
> SparkGraphComputer.configure("spark.master","local[4]").configure("gremlin.spark.graphStorageLevel","MEMORY_AND_DISK")...etc.
> {code}
> Likewise for Giraph and its standard configurations.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
