[jira] [Commented] (TINKERPOP-942) Use EventStrategy to solve OLAP bulk mutation of OLTP.

["Marko A. Rodriguez (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/TINKERPOP-942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15151235#comment-15151235 ] 

Marko A. Rodriguez commented on TINKERPOP-942:
----------------------------------------------

Now that an OLAP traversal can have multiple OLAP jobs within it, perhaps every {{Mutating}}-step appends a {{BulkLoaderVertexProgram.IncrementalStep}} ?? ... 

> Use EventStrategy to solve OLAP bulk mutation of OLTP.
> ------------------------------------------------------
>
>                 Key: TINKERPOP-942
>                 URL: https://issues.apache.org/jira/browse/TINKERPOP-942
>             Project: TinkerPop
>          Issue Type: Improvement
>          Components: process
>    Affects Versions: 3.1.0-incubating
>            Reporter: Marko A. Rodriguez
>            Assignee: Daniel Kuppitz
>             Fix For: 3.2.0-incubating
>
>
> We need to be able to do this in TinkerPop3.
> https://github.com/thinkaurelius/faunus/wiki/Distributed-Graph-Computing-with-Gremlin
> This can be solved with {{EventStrategy}}. 
> Lets think of the hardest problem first -- distributed graph database (e.g. Titan) being mutated by a distributed graph processor (e.g. Giraph). Each Giraph node will map to a Titan node. Then the Giraph node will create a connection back to the respective Titan node via the {{writeGraph}} model by [~dkuppitz] in {{BulkLoaderVertexProgram}}. Every time a {{addV()}}, {{addE()}}, {{property()}} is called, an event is fired and THAT event is call back to the Titan to create the vertex/edge/property. Likewise for {{drop()}}, etc. In other words, all {{Mutating}} steps can have a call back in OLAP to mutate the OLTP system.
> What about the easy case of {{TInkerGraph}} OLAP talking to {{TinkerGraph}} OLTP? Well, this gets back to {{GraphComputer.RESULT_GRAPH}} and whether your graph computer is operating over the real graph or a clone of it. However, I think its just the same as TItan/Giraph-style.
> So what is this good for?
> * Drop all the "knows" edges.
> * Change all the date properties from {{java.util.Date}} to {{Long}}.
> * Infer all {{foaf}}-edges.
> * etc.
> Things to consider -- transactions.
> If we solve this cleanly, then that is truly the final "big hurdle" in the {{GraphComputer}} story.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)