Jake Mannix commented on GIRAPH-36:

Initial thoughts:

  VertexReader defines a "next(MutableVertex vertex)" method, which does the 
sensible thing of filling in the vertex from the HDFS block, and because it 
takes a vertex object and messes with it, it's natural that the vertex be 
"required" to be a MutableVertex.

  But of course this implies that *everything* be a MutableVertex, because if 
you can't be read in by a VertexReader, where do you get instantiated at all?  
If BasicVertex implements Writable, we could always readFields() data in, but 
not allow mutation, but this seems like it would interfere with the way 
VertexReader allows users to read straight from Text, etc.  This would allow 
VertexList to extend ArrayList<BasicVertex> instead of ArrayList<Vertex>, at 
the same time.

Anyone have any thoughts/ideas?  Are we wedded to making VertexReader 
implementations deal with MutableVertex, or can we swap them to handle Writable 

> Ensure that subclassing BasicVertex is possible by user apps
> ------------------------------------------------------------
>                 Key: GIRAPH-36
>                 URL: https://issues.apache.org/jira/browse/GIRAPH-36
>             Project: Giraph
>          Issue Type: Improvement
>          Components: graph
>    Affects Versions: 0.70.0
>            Reporter: Jake Mannix
>            Assignee: Jake Mannix
>            Priority: Blocker
>             Fix For: 0.70.0
> Original assumptions in Giraph were that all users would subclass Vertex 
> (which extended MutableVertex extended BasicVertex).  Classes which wish to 
> have application specific data structures (ie. not a TreeMap<I, Edge<I,E>>) 
> may need to extend either MutableVertex or BasicVertex.  Unfortunately 
> VertexRange extends ArrayList<Vertex>, and there are other places where the 
> assumption is that vertex classes are either Vertex, or at least 
> MutableVertex.
> Let's make sure the internal APIs allow for BasicVertex to be the base class.

This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


Reply via email to