[ 
https://issues.apache.org/jira/browse/FLINK-1523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14505053#comment-14505053
 ] 

ASF GitHub Bot commented on FLINK-1523:
---------------------------------------

Github user andralungu commented on a diff in the pull request:

    https://github.com/apache/flink/pull/537#discussion_r28785218
  
    --- Diff: 
flink-staging/flink-gelly/src/main/java/org/apache/flink/graph/spargel/VertexCentricIteration.java
 ---
    @@ -138,69 +146,46 @@ public void setInput(DataSet<Vertex<VertexKey, 
VertexValue>> inputData) {
                if (this.initialVertices == null) {
    --- End diff --
    
    I made that division in order to avoid having duplicate code: the number of 
vertices and the direction are totally independent of the "degree" option which 
is why they can  be set in the createResult() method. Afterwards, the code does 
exactly what you described in this comment: it separates the creation of a 
delta iteration and the creation of the messaging function plus vertex update 
function according to the vertex type(with degrees or not). It's not just the 
vertex that changes, but everything that uses its value afterwards changes too. 
I suggest you look a bit closer at the createResultVerticesWithDegrees and 
createResultSimpleVertex methods. I don't think their functionality can be 
simplified by just creating a simple vertex and a vertex with degrees. 


> Vertex-centric iteration extensions
> -----------------------------------
>
>                 Key: FLINK-1523
>                 URL: https://issues.apache.org/jira/browse/FLINK-1523
>             Project: Flink
>          Issue Type: Improvement
>          Components: Gelly
>            Reporter: Vasia Kalavri
>            Assignee: Andra Lungu
>
> We would like to make the following extensions to the vertex-centric 
> iterations of Gelly:
> - allow vertices to access their in/out degrees and the total number of 
> vertices of the graph, inside the iteration.
> - allow choosing the neighborhood type (in/out/all) over which to run the 
> vertex-centric iteration. Now, the model uses the updates of the in-neighbors 
> to calculate state and send messages to out-neighbors. We could add a 
> parameter with value "in/out/all" to the {{VertexUpdateFunction}} and 
> {{MessagingFunction}}, that would indicate the type of neighborhood.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to