Hi Andre, I'd be also very interested in the type of extension you're proposing. As a matter of fact I ended up implementing that kind of vertex by myself, you can have an example here: https://github.com/claudiomartella/graffiti/blob/master/src/main/java/org/acaro/graffiti/processing/Vertex.java
As you can see I end up breaking most of the API adding my own multigraph API internally. As I see it, we'd basically have to move all the API about edges from single object to Iterable (i.e. returning multiple edges for a given vertex endpoint as you suggested), and maybe also returning multiple vertices for a given edge(label). The single-graph, as it's implemented now compared to multi-graph, would be a subcase of this which internally it would return getEdgeValue().iterator().next(). I'd be +1 for such an extension. On Fri, Feb 3, 2012 at 10:44 AM, André Kelpe <efeshundert...@googlemail.com> wrote: > Hi list, > > in my current usage of giraph I ran into the limitation that the API is > centered > around simple graphs but in many applications you are actually dealing with > multi-graphs. One simple example is a road network, where there can be n edges > between 2 vertices. For my current program I could work around the > "limitation" > by using an ArrayWritable as the edge value, which contains all edges that are > connectors to a neighbour vertex. That is however not the cleanest of all > approaches. > > The pregel paper describes an API, where you work with iterators to all your > outgoing edges and you then can access the vertex on the other end with a > method > call (see the impl of Shortest Path in the paper). That kind of API would > totally allow having multiple edges connecting the same two vertices directly > while the current API with getEdgeValue(vertexId) does not. What is the > current > view on this, is that a feature, that would be welcome? Should I open a JIRA > for the discussion? Am I overlooking something? > > Thanks! > > André -- Claudio Martella claudio.marte...@gmail.com
