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
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
<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

Reply via email to