Return-Path: X-Original-To: apmail-incubator-giraph-user-archive@minotaur.apache.org Delivered-To: apmail-incubator-giraph-user-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 9A25A827C for ; Tue, 13 Sep 2011 16:44:10 +0000 (UTC) Received: (qmail 47154 invoked by uid 500); 13 Sep 2011 16:44:10 -0000 Delivered-To: apmail-incubator-giraph-user-archive@incubator.apache.org Received: (qmail 47130 invoked by uid 500); 13 Sep 2011 16:44:10 -0000 Mailing-List: contact giraph-user-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: giraph-user@incubator.apache.org Delivered-To: mailing list giraph-user@incubator.apache.org Received: (qmail 47114 invoked by uid 99); 13 Sep 2011 16:44:10 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 13 Sep 2011 16:44:10 +0000 X-ASF-Spam-Status: No, hits=4.0 required=5.0 tests=FREEMAIL_FROM,FREEMAIL_REPLY,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of jake.mannix@gmail.com designates 74.125.83.47 as permitted sender) Received: from [74.125.83.47] (HELO mail-gw0-f47.google.com) (74.125.83.47) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 13 Sep 2011 16:44:04 +0000 Received: by gwb11 with SMTP id 11so897721gwb.6 for ; Tue, 13 Sep 2011 09:43:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=NJo5FTGaWF7V9SMH+uZhgEzGU2Z96IuobLVc1cFq7tk=; b=DTqs/HfvhNQnc+sjGUNbmpV/FvjFVzHfsB+BdzJF4fw0nUZj++g/V/uED+f1hBna62 ey7gXEYZ1edSiGankrr+d/DwBgpPlvPUMDQkasiYlfKZlAg2JhaM2QzZqii5W/SBCmRM TmPL2b7unf1Wt04b9xRYr/nOXc46p41Faec+Y= Received: by 10.150.104.16 with SMTP id b16mr3583627ybc.117.1315932223413; Tue, 13 Sep 2011 09:43:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.98.4 with HTTP; Tue, 13 Sep 2011 09:43:23 -0700 (PDT) In-Reply-To: References: From: Jake Mannix Date: Tue, 13 Sep 2011 09:43:23 -0700 Message-ID: Subject: Re: ValueIndexed OutEdgeMap To: giraph-user@incubator.apache.org Content-Type: multipart/alternative; boundary=000e0cd48c5cb99ef104acd55834 --000e0cd48c5cb99ef104acd55834 Content-Type: text/plain; charset=ISO-8859-1 I actually think the name should be reversed: everything "is a Vertex", so that should be the base abstract class, and BasicVertex (or SimpleVertex) should maybe be the name of "the simplest generic implementation" - ie what is now called Vertex. And yes, then document clearly when you should subclass which one. -jake On Tue, Sep 13, 2011 at 9:37 AM, Dmitriy Ryaboy wrote: > We should add that to Vertex's javadoc... > > > On Tue, Sep 13, 2011 at 9:31 AM, Jake Mannix 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 < >> claudio.martella@gmail.com> 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 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 < >>>> claudio.martella@gmail.com> 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> 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 >>>>> claudio.martella@gmail.com >>>>> >>>> >>>> >>> >>> >>> -- >>> Claudio Martella >>> claudio.martella@gmail.com >>> >> >> > > > -- > Dmitriy V Ryaboy > Twitter Analytics > http://twitter.com/squarecog > > --000e0cd48c5cb99ef104acd55834 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I actually think the name should be reversed: everything "is a Vertex&= quot;, so that should be the base abstract class, and BasicVertex (or Simpl= eVertex) should maybe be the name of "the simplest generic implementat= ion" - ie what is now called Vertex.

And yes, then document clearly when you should subclass whic= h one.

=A0 -jake

On Tue, Sep 13, 2011 at 9:37 AM, Dmitriy Ryaboy <dmitriy@twitter.com> wrote= :
We should add that to Vertex's javadoc.= ..


On T= ue, Sep 13, 2011 at 9:31 AM, Jake Mannix <jake.mannix@gmail.com>= ; wrote:
Claudio,

=A0 If your vert= ex class has special internal data structures, what you'll want to do i= s subclass either BasicVertex, or MutableVertex, not Vertex. =A0And then ye= s, add a "getEdgesByValue()" or whatever to that class.

=A0 -jake


On Tue, Sep 13, 2011 at 8:22 AM, C= laudio Martella <claudio.martella@gmail.com> wrote:=
Hi Jake,

thanks for the f= eedback. I checked out the patch, but it looks like it's changing just = the "read" access visibility. How could I provide a "value&q= uot;-indexed internal datastructure according to the new api? the new addEd= ge is stil final. I can add my own "getEdgesByValue()" (as I migh= t have more outedges with the same label) to my own vertex, but i must be a= ble to modify override the addEdge() somehow.


On Tue, Sep 13, 2011 at 4:55 PM, Jake Mannix= <jake.mannix@gmail.com> wrote:
Hi Claudio,

=A0 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)?

=A0 Check out:=A0https://issues.apache.org/jira/brow= se/GIRAPH-31 - this change, if merged to trunk, would allow you to keep= whatever edge datastructure you wanted, and implement your own internal st= ructures. =A0Try out that patch, give a comment on the JIRA if you've g= ot any thoughts!

=A0 -jake


On Tue, Sep 13, 2011 at 3:09 AM, C= laudio Martella <claudio.martella@gmail.com> wrote:=
Hello list,

I'm curre= ntly implementing large scale path traversals over an RDF graph. the traver= sals 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 lab= el (value), without iterating through the whole vertex edge list looking fo= r them (given avg vertex degree of K i'd go from O(K) to O(logK) at lea= st). 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?

T= IA

--
=A0 =A0 C= laudio Martella
=A0 =A0 claudio.martella@gmail.com




--
=
=A0 =A0 Claudio Martella
=A0 =A0 claudio.martella@gmail.com




--
Dmitriy V Ryaboy
Twitter Analytics
http://twitter.com/squa= recog


--000e0cd48c5cb99ef104acd55834--