[jira] [Updated] (TINKERPOP-1113) GraphComputer subclasses should support native methods

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

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

Marko A. Rodriguez updated TINKERPOP-1113:
------------------------------------------
    Summary: GraphComputer subclasses should support native methods  (was: GraphComputer subclasses should support native methods\)

> 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
>
> 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
(v6.3.4#6332)