On Tue, Sep 13, 2011 at 3:34 PM, Claudio Martella <
claudio.marte...@gmail.com> wrote:

> ok, i understand. you suggest i IMPLEMENT BasicVertex and encapsulate
> Vertex. This sounds like a possibility. Still I think there should be
> an implementation without final addEdge (as the rest isn't final).
>

BasicVertex is now an abstract class, not an interface, which implements
some
of the required functionality.   MutableVertex defines addEdge() as
an abstract method, so if you extend MutableVertex, you can have it add to
your own data structure - do *not* encapsulate a Vertex, just do what you
need
in your MutableVertex subclass.

Vertex has a final addEdge() method, because its subclasses are depending
on the fact that it's adding edges to the TreeMap that it contains.

  -jake


>
> On Tue, Sep 13, 2011 at 6:31 PM, Jake Mannix <jake.man...@gmail.com>
> wrote:
> > Claudio,
> >   If your vertex class has special internal data structures, what you'll
> > want to do is subclass either BasicVertex, or MutableVertex, not Vertex.
> >  And then yes, add a "getEdgesByValue()" or whatever to that class.
> >   -jake
> >
> > On Tue, Sep 13, 2011 at 8:22 AM, Claudio Martella
> > <claudio.marte...@gmail.com> wrote:
> >>
> >> Hi Jake,
> >> thanks for the feedback. I checked out the patch, but it looks like it's
> >> changing just the "read" access visibility. How could I provide a
> >> "value"-indexed internal datastructure according to the new api? the new
> >> addEdge is stil final. I can add my own "getEdgesByValue()" (as I might
> have
> >> more outedges with the same label) to my own vertex, but i must be able
> to
> >> modify override the addEdge() somehow.
> >>
> >> On Tue, Sep 13, 2011 at 4:55 PM, Jake Mannix <jake.man...@gmail.com>
> >> wrote:
> >>>
> >>> Hi Claudio,
> >>>   So what you want is to be able to build up your own
> >>> application-specific data structure for the outbound edges of a vertex
> (in
> >>> your case, one that effectively supports fulltext search on the edge
> >>> values)?
> >>>   Check out: https://issues.apache.org/jira/browse/GIRAPH-31 - this
> >>> change, if merged to trunk, would allow you to keep whatever edge
> >>> datastructure you wanted, and implement your own internal structures.
>  Try
> >>> out that patch, give a comment on the JIRA if you've got any thoughts!
> >>>   -jake
> >>>
> >>> On Tue, Sep 13, 2011 at 3:09 AM, Claudio Martella
> >>> <claudio.marte...@gmail.com> wrote:
> >>>>
> >>>> Hello list,
> >>>> I'm currently implementing large scale path traversals over an RDF
> >>>> graph. the traversals are defined by the starting vertex and a set of
> edge
> >>>> labels that have to be traversed, if possible, to obtain all the
> wanted
> >>>> paths. In my current scenario the vertexID is Text, and the Edge is
> <Text,
> >>>> Text> as well, as the edge value is the edge label. For obvious
> reasons, it
> >>>> would be much more efficient to be able to obtain all the edges with a
> >>>> matching Edge label (value), without iterating through the whole
> vertex edge
> >>>> list looking for them (given avg vertex degree of K i'd go from O(K)
> to
> >>>> O(logK) at least). I thought about creating my own labelledOutEdgeMap
> and
> >>>> populate it by overriding Vertex.addEdge(), but that's final. I
> thought
> >>>> about adding a method but VertexReader.next() is receiving a
> MutableVertex.
> >>>> Do you have any suggestions?
> >>>> TIA
> >>>>
> >>>> --
> >>>>     Claudio Martella
> >>>>     claudio.marte...@gmail.com
> >>>
> >>
> >>
> >>
> >> --
> >>     Claudio Martella
> >>     claudio.marte...@gmail.com
> >
> >
>
>
>
> --
>     Claudio Martella
>     claudio.marte...@gmail.com
>

Reply via email to