[
https://issues.apache.org/jira/browse/FLINK-1523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14528386#comment-14528386
]
ASF GitHub Bot commented on FLINK-1523:
---------------------------------------
Github user vasia commented on the pull request:
https://github.com/apache/flink/pull/537#issuecomment-99070508
Hey @andralungu ,
I'm not sure what @StephanEwen had in mind when suggesting to subclass
Vertex, but the current implementation forces the user to cast the `Vertex` to
`VertexWithDegrees` in order to access the degrees, which is not a very
user-friendly :S
I guess the point was to have `VertexWithDegrees` as an argument to the
update and messaging functions instead? If that's the case however, it's not
quite clear to me how this will play along with the configuration option
setting.
Back to my previous comment on only accessing the degrees inside the
update/messaging functions instead of adding public methods to the Vertex
class, a simple way to do this would be the following:
Add set/get vertexDegree methods in `VertexUpdateFunction` and
`MessagingFunction`. These would be the methods that the user will call to
access the vertex degrees, in a way similar to `getDirection()`,
`getBroadcastSet()` etc.
Inside `createResultVerticesWithDegrees`, you're already creating the
"augmented" vertex dataset with the degrees and pass this as the solution set
of the delta iteration. Then, in the corresponding coGroup method of the
Messaging/VertexUpdate UDFs, you iterate over this dataset (state) and call the
user-defined functions for each vertex. This is where you can set the degrees
inside the update/messaging functions, instead of how you currently set them on
the vertex object.
What do you think of this solution?
> 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)
