Oh, misunderstanding. My code (github's I guess) and the javadoc on the apache site showed BasicVertex as an interface. Now everything makes sense.
Thanks for the feedback, made my day! On Wed, Sep 14, 2011 at 1:01 AM, Jake Mannix <[email protected]> wrote: > > On Tue, Sep 13, 2011 at 3:34 PM, Claudio Martella > <[email protected]> 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 <[email protected]> >> 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 >> > <[email protected]> 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 <[email protected]> >> >> 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 >> >>> <[email protected]> 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 >> >>>> [email protected] >> >>> >> >> >> >> >> >> >> >> -- >> >> Claudio Martella >> >> [email protected] >> > >> > >> >> >> >> -- >> Claudio Martella >> [email protected] > > -- Claudio Martella [email protected]
