[
https://issues.apache.org/jira/browse/TINKERPOP3-373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14490280#comment-14490280
]
Matthias Broecheler commented on TINKERPOP3-373:
------------------------------------------------
So, this is how I implemented this for Fulgora:
- Nothing does nothing. Easy. Just discard all the results from the
VertexProgram
- Fulgora only supports VERTEX_PROPERTIES (i.e. Titan doesn't support adding
edges in OLAP).
- NEW = Creates a new transaction to write the vertex properties of the
VertexProgram into. That transaction is not committed but handed to the user as
is. In that way, it is kind of between NEW and VIEW. NEW as in creating a copy
of the Titan graph is not feasible. This only works for relatively small graphs
since the entire transaction state needs to be held in memory.
- ORIGINAL = Writes all properties back to Titan and persists them. Does this
"intelligently" so that this scales better. After the VertexProgram completes
the user can read the results from Titan like any other property.
That said, Fulgora cannot support a real NEW or an entirely separate VIEW as
TinkerGraph. But I think the above works if the test cases no longer
distinguish between compute keys and other keys after the computation is
finished.
> GraphComputer property persistence options
> ------------------------------------------
>
> Key: TINKERPOP3-373
> URL: https://issues.apache.org/jira/browse/TINKERPOP3-373
> Project: TinkerPop 3
> Issue Type: Improvement
> Components: process
> Reporter: Matthias Broecheler
> Assignee: Marko A. Rodriguez
>
> I noticed that the implicit assumption is that element compute keys (and the
> values associated with them during the vertex computer iterations) are
> persisted back into the graph after termination.
> Two thoughts on this:
> 1) There should be an option to disable this. For instance, one might want to
> run PageRank and then run a map-reduce job to determine the 10 hightest
> ranked vertices. If it is required that all PR values are being written back
> into the graph that would become prohibitively expensive on large graphs.
> 2) It should be possible to define which subset of the elementComputeKeys one
> wants to persist back into the graph. For instance, for PR one typically only
> wants the PR value and not the edge-count
> ===> Vertex.getElementComputeKeys() should return a Map<String,Boolean> where
> the boolean value indicates whether the value should be persisted back into
> the graph. If all are false, then nothing is written back as required in (1).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
