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

Daniel Kuppitz commented on TINKERPOP-1974:
-------------------------------------------

This is by design and you really shouldn't try to mutate edges in an OLAP 
graph. I think even your workaround doesn't really do what you think it does. 
Since you only have access to the local star-graph, any attempt to create an 
edge could only result in an unidirected edge (meaning the vertex on the other 
side will not be notified about the new edge).

What you usually want to do is pass a reference to the underlying OLTP graph to 
your VertexProgram and then use this graph to create new edges (or remove 
existing edges). This works for any provider implementation. However, keep in 
mind that OLAP jobs are usually multi-threaded, but TinkerGraph won't support 
parallel mutations of the graph; hence you'll have to execute the VertexProgram 
using a single worker thread.

If you're not trying to mutate the original graph and the edges were supposed 
to be temporary, consider to remodel them as vertex properties.

> Adding edges during VertexProgram execute with Tinkergraph backend results in 
> ClassCastException
> ------------------------------------------------------------------------------------------------
>
>                 Key: TINKERPOP-1974
>                 URL: https://issues.apache.org/jira/browse/TINKERPOP-1974
>             Project: TinkerPop
>          Issue Type: Bug
>          Components: tinkergraph
>    Affects Versions: 3.3.3
>            Reporter: Nathaniel Meyer
>            Priority: Minor
>
> Attempts to add edges during a vertex program on tinkergraph result in a 
> ClassCastException because 
> org.apache.tinkerpop.gremlin.process.computer.util.ComputerGraph.ComputerVertex
>  can't be cast to class 
> org.apache.tinkerpop.gremlin.tinkergraph.structure.TinkerVertex.
> In a vertex program designed to add edges to the graph based on rules, 
> attempts to call vertex.addEdge(label,otherVertex,edgeProperties) can only 
> result in a ClassCastException on Tinkergraph.  At runtime, the Vertex 
> argument to VertexProgram.execute(vertex,messenger,memory) has class 
> org.apache.tinkerpop.gremlin.process.computer.util.ComputerGraph.ComputerVertex.
>   Both the vertex and the otherVertex are instances of class 
> ComputerGraph.ComputerVertex, but when addEdge is called on the 
> ComputerGraph.ComputerVertex instance, internally it calls the addEdge(...) 
> of the wrapped TinkerVertex.  TinkerVertex.addEdge(...) casts the otherEdge 
> to a TinkerVertex, which it is not.  There is no way to get an instance of a 
> TinkerVertex in a VertexProgram without specifically handling this case, 
> casting to ComputerGraph.ComputerVertex or WrappedVertex, and getting the 
> wrapped vertex of the other vertex before calling addEdge.  This is not 
> portable across backends!
> A fix might be to add handling for instances of ComputerGraph.ComputerVertex 
> or <C extends WrappedVertex> and get the base vertex before casting to 
> TinkerVertex.
> EDIT: Workaround exists, downgrade to minor.  Added test for 
> WrappedVertex.class in my vertex program and performed a getBaseVertex() call 
> on the target vertex before calling addEdge.  
> if(WrappedVertex.class.isAssignableFrom(mate.getClass())) {                   
>  
>       vertex.addEdge("similarTo", 
> ((WrappedVertex<Vertex>)mate).getBaseVertex(), edgeProperties);
> } else {
>       vertex.addEdge("similarTo", mate, edgeProperties);
> }



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to