Hi,
In OLAP (GraphComputer), we have the enums ResultGraph and Persist.
https://github.com/apache/incubator-tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/computer/GraphComputer.java#L33-L57
My original intention with ResultGraph was that if you did ResultGraph.ORIGINAL
then the original graph would be updated with all the changes from the mutated
GraphComputer graph. However, this isn't working out like I planned and in
fact, I think we should get rid of the concept of ResultGraph.
https://issues.apache.org/jira/browse/TINKERPOP-1074
For SparkGraphComputer and GiraphGraphComputer, ResultGraph.ORIGINAL is not
supported. For TinkerGraphComputer, it is. TinkerGraphComputer creates a "view"
over the original graph and if you ResultGraph.ORIGINAL, that view is merged
with the original graph.
If ResultGraph.ORIGINAL no longer exists, how is GraphComputer data suppose to
get back to the original graph. The answer lies in Daniel Kuppitz' work on
BulkLoaderVertexProgram. With GraphComputer, you can chain together
computations where:
[PageRankVertexProgram,BulkLoaderVertexProgram]
….would pull from a Graph, PageRank OLAP, and then write the results back to
the original graph (or some other graph!) via BulkLoader OLAP.
I think this is how it should be done. This will simplify testing, reduce
complexity, and provide one model by which GraphComputer data is sent back to
the original graph.
*** This change would primarily effect graph system providers that support
ResultGraph.ORIGINAL. I don't think there are many. I know that TinkerGraph and
FulgoraGraph (Titan) support it, but no others… Users will simply have one less
method in their VertexPrograms and off of GraphComputer (though @Deprecate will
make it backwards compatible for them).
Thoughts?,
Marko.
http://markorodriguez.com
