Hi,
Here are some design decisions.
//////////
GraphComputer and GraphActors now implement a “marker interface” called
Processor.
//////////
Graph.compute()
I don’t like this method anymore as when all this work is complete, any
GraphComputer/GraphActors can work against any Graph as they will work against
Partitioner, not Graph and thus, they don’t care about the Graph interface.
Thus, I propose we deprecate Graph.compute().
//////////
Thus, you create a Processor for a Graph via:
SparkGraphComputer.build().graph(Graph).workers(int).program(VertexProgram).submit()
AkkaGraphActors.build().graph(Graph).workers(int).program(ActorProgram).submit()
Generally:
GraphComputer.build(SparkGraphComputer.class).graph(Graph).workers()…
//////////
For using a Processor to evaluate a traversal we have withProcessor().
g = graph.traversal().withProcessor(AkkaGraphActors.class) // default settings
g = graph.traversal().withProcessor(AkkaGraphActors.build().workers()…) //
specified settings (any Graph or Program settings will be overwritten)
This means that Computer goes away. Its a pointless fluent builder and we can
just use a static fluent builder off the GraphComputer (and GraphActors)
classes.
g =
graph.traversal().withProcessor(SparkGraphComputer.build().workers().edges().vertices()….)
//////////
So, we have a way of turning every TraversalStrategy into a Configuration which
for Gremlin variants is just a Map. Thus, in Gremlin-Python:
g =
graph.traversal().withProcessor([graphComputer:“SparkGraphComputer”,workers:10])
How does this related to TraversalStrategies?
Processor.getTraversalStrategies(TraversalSource source)
Thoughts?,
Marko.
http://markorodriguez.com
