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
you can have an example here:
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
I'd be +1 for such an extension.
On Fri, Feb 3, 2012 at 10:44 AM, André Kelpe
> Hi list,
> in my current usage of giraph I ran into the limitation that the API is
> 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
> 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
> 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
> 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
> view on this, is that a feature, that would be welcome? Should I open a JIRA
> for the discussion? Am I overlooking something?