Uploaded image for project: 'TinkerPop'
  1. TinkerPop
  2. TINKERPOP-1113

GraphComputer subclasses should support native methods

    XMLWordPrintableJSON

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Major
    • Resolution: Done
    • Affects Version/s: 3.1.0-incubating
    • Fix Version/s: 3.4.0, 3.3.4, 3.2.10
    • Component/s: process
    • Labels:
      None

      Description

      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:

      SparkGraphComputer.master(String).persistContext(boolean).graphStorageLevel(StorageLevel).persistStorageLevel(StorageLevel)
      

      This way, we have a clear API with typing and pre-execution checking! instead of what people would do now:

      SparkGraphComputer.configure("spark.master","local[4]").configure("gremlin.spark.graphStorageLevel","MEMORY_AND_DISK")...etc.
      

      Likewise for Giraph and its standard configurations.

        Attachments

          Activity

            People

            • Assignee:
              spmallette Stephen Mallette
              Reporter:
              okram Marko A. Rodriguez
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: