Marko A. Rodriguez created TINKERPOP-1113:
---------------------------------------------
Summary: 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)
