giraph-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Claudio Martella (Commented) (JIRA)" <>
Subject [jira] [Commented] (GIRAPH-36) Ensure that subclassing BasicVertex is possible by user apps
Date Wed, 19 Oct 2011 12:40:11 GMT


Claudio Martella commented on GIRAPH-36:

I understand. well, although I don't see how it could be really optimized on the fact a class
doesn't present a subset of the methods (the mutating methods) on performance, I could understand
on a principle.

Anyway I think it could make sense to follow your distinction between mutation before and
after instantiation, and I believe a good way of doing this could be:

(a) initialize the object through Writable interface readField() at instantiation. This would
allow us basically to re-use code we already have (readField() implementation) and not break
any underlying assumption about mutation. The bad part is that people would have to provide
storage on DataInputStream instead of the current VertexInputFormat.

(b) explicitly create initialize() method to do the "pre instantiation" init code, which would
be added to BasicVertex. This code would be called inside of for
instance by passing the content of RecordReader.getCurrentValue(), i.e. vertex.initialize(getRecordReader().getCurrentValue()).
This is probably the cleanest solution as it doesn't require to change the current API and
also quite matches with the Factory-based current creation of vertices.
> Ensure that subclassing BasicVertex is possible by user apps
> ------------------------------------------------------------
>                 Key: GIRAPH-36
>                 URL:
>             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.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


View raw message