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?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
