[
https://issues.apache.org/jira/browse/GIRAPH-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13139923#comment-13139923
]
Jake Mannix commented on GIRAPH-36:
-----------------------------------
Hey Avery,
Glad you could get it to all work (unit-test-wise) for you - did you run the
unit tests talking to a real cluster, or just localhost? I haven't tried the
former yet...
Regarding the comments: I'm fine keeping GraphState hidden to the
implementation details, but will it always work in practice? I mean, all of
the state in there used to be global static state in Vertex, and all subclasses
had full read/write access to it. We've segregated it in a non-static object
which we're treating as a singleton (but aren't forcing it to be one
programmaticly), but can we really hide it?
For example, BasicVertex#sendMsg() requires the WorkerCommunications, which
it gets from the GraphMapper, which it gets from the GraphState. Do you think
we should implement all the things we think the user will need from the
GraphMapper directly *in* BasicVertex (or MutableVertex), and remove the
getGraphState() method entirely, or just keep it package private for now.
In general, I like keeping impl details away from developers too, but this
early in the project, we also shouldn't hamstring ourselves by thinking there
is a difference from a "casual user" of the system, and someone willing to hack
around a bit. :)
2) If VertexReader is going to return a BasicVertex<I,V,E,M> from
getCurrentVertex() to callers who really need it to be fully specified nice and
type-safely, what choice do we have? From a pratical, rather than API
standpoint, is it possible we'd someday want to be able to read up a collection
of vertices with initial messages ready to be processed? Not sure if that
matters.
3) I tried, and can clean up as possible, but I really rely on my IDE
settings for that. Not being able to set autoformat on means I'm pretty
doomed, but if you see places where I can clean up manually, I can do that,
sure.
> 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
>
> Attachments: GIRAPH-36.diff
>
>
> 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:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
