[
https://issues.apache.org/jira/browse/FLINK-5892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15984845#comment-15984845
]
ASF GitHub Bot commented on FLINK-5892:
---------------------------------------
Github user StefanRRichter commented on a diff in the pull request:
https://github.com/apache/flink/pull/3770#discussion_r113412507
--- Diff:
flink-runtime/src/main/java/org/apache/flink/runtime/jobgraph/JobVertexID.java
---
@@ -40,6 +40,10 @@ public JobVertexID(long lowerPart, long upperPart) {
super(lowerPart, upperPart);
}
+ public JobVertexID(AbstractID id) {
--- End diff --
Different subclasses of AbstractID are intended to introduce some kind of
type safety. With this in mind, I feel like this is a not very transparent way
of "casting" between Ids. Maybe some `convert` methods could make this a bit
more explicit than offering a public constructor for this purpose?
> Recover job state at the granularity of operator
> ------------------------------------------------
>
> Key: FLINK-5892
> URL: https://issues.apache.org/jira/browse/FLINK-5892
> Project: Flink
> Issue Type: New Feature
> Components: State Backends, Checkpointing
> Reporter: Guowei Ma
> Assignee: Guowei Ma
>
> JobGraph has no `Operator` info so `ExecutionGraph` can only recovery at the
> granularity of task.
> This leads to the result that the operator of the job may not recover the
> state from a save point even if the save point has the state of operator.
>
> https://docs.google.com/document/d/19suTRF0nh7pRgeMnIEIdJ2Fq-CcNVt5_hR3cAoICf7Q/edit#.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
