Return-Path: 
 <giraph-dev-return-2197-apmail-incubator-giraph-dev-archive=incubator.apache.org@incubator.apache.org>
X-Original-To: apmail-incubator-giraph-dev-archive@minotaur.apache.org
Delivered-To: apmail-incubator-giraph-dev-archive@minotaur.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id C120AC099
	for <apmail-incubator-giraph-dev-archive@minotaur.apache.org>;
 Thu, 10 May 2012 08:18:10 +0000 (UTC)
Received: (qmail 92934 invoked by uid 500); 10 May 2012 08:18:10 -0000
Delivered-To: apmail-incubator-giraph-dev-archive@incubator.apache.org
Received: (qmail 92890 invoked by uid 500); 10 May 2012 08:18:10 -0000
Mailing-List: contact giraph-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:giraph-dev-help@incubator.apache.org>
List-Unsubscribe: <mailto:giraph-dev-unsubscribe@incubator.apache.org>
List-Post: <mailto:giraph-dev@incubator.apache.org>
List-Id: <giraph-dev.incubator.apache.org>
Reply-To: giraph-dev@incubator.apache.org
Delivered-To: mailing list giraph-dev@incubator.apache.org
Received: (qmail 92842 invoked by uid 99); 10 May 2012 08:18:08 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 10 May 2012 08:18:08 +0000
X-ASF-Spam-Status: No, hits=-2000.0 required=5.0
	tests=ALL_TRUSTED,T_RP_MATCHES_RCVD
X-Spam-Check-By: apache.org
Received: from [140.211.11.116] (HELO hel.zones.apache.org) (140.211.11.116)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 10 May 2012 08:18:06 +0000
Received: from hel.zones.apache.org (hel.zones.apache.org [140.211.11.116])
	by hel.zones.apache.org (Postfix) with ESMTP id E006148E4EE
	for <giraph-dev@incubator.apache.org>; Thu, 10 May 2012 08:17:44 +0000 (UTC)
Date: Thu, 10 May 2012 08:17:44 +0000 (UTC)
From: "Roman K (JIRA)" <jira@apache.org>
To: giraph-dev@incubator.apache.org
Message-ID: 
 <662912925.48621.1336637864991.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <706315194.11050.1328347193792.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (GIRAPH-141) mulitgraph support in giraph
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394


    [ https://issues.apache.org/jira/browse/GIRAPH-141?page=3Dcom.atlassian=
.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D1327=
2177#comment-13272177 ]=20

Roman K commented on GIRAPH-141:
--------------------------------

I think the best thing to do is to implement multigraph separately from sim=
ple graph, make some benchmarks to see the performance and memory usage imp=
acts on processing (simple graph as multigraph) vs (simple graph) . If the =
impact could be neglected, refactor the code and leave the multigraph imple=
mentation only.

Another, more specific question, is what should be done with methods like
{quote}
  /**
   * Request to remove a vertex from the graph
   * (applied just prior to the next superstep).
   *
   * @param vertexId Id of the vertex to be removed.
   */
public void removeEdgeRequest(I sourceVertexId, I destVertexId)
{quote}
For multigraphs, behavior for this method is quiet undefined.
May be=20
{quote}
public void removeEdgeRequest(I sourceVertexId, I destVertexId, E edgeValue=
)
{quote}
should be introduced?
               =20
> mulitgraph support in giraph
> ----------------------------
>
>                 Key: GIRAPH-141
>                 URL: https://issues.apache.org/jira/browse/GIRAPH-141
>             Project: Giraph
>          Issue Type: Improvement
>          Components: graph
>            Reporter: Andr=C3=A9 Kelpe
>
> The current vertex API only supports simple graphs, meaning that there ca=
n only ever be one edge between two vertices. Many graphs like the road net=
work are in fact multigraphs, where many edges can connect two vertices at =
the same time.
> Support for this could be added by introducing an Iterator<EdgeWritable> =
getEdgeValue() or a similar construct. Maybe introducing a slim object like=
 a Connector between the edge and the vertex is also a good idea, so that y=
ou could do something like:
> {code}=20
> for (final Connector<EdgeWritable, VertexWritable> conn: getEdgeValues(){
>      final EdgeWritable edge =3D conn.getEdge();
>      final VertexWritable otherVertex =3D conn.getOther();
>      doInterestingStuff(otherVertex);
>      doMoreInterestingStuff(edge);
> }
> {code}=20

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrato=
rs: https://issues.apache.org/jira/secure/ContactAdministrators!default.jsp=
a
For more information on JIRA, see: http://www.atlassian.com/software/jira