GraphActors and GraphComputers design decisions for 3.3.0-SNAPSHOT.

[Marko Rodriguez <ok...@gmail.com>]

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