[
https://issues.apache.org/jira/browse/FLINK-8978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16462589#comment-16462589
]
ASF GitHub Bot commented on FLINK-8978:
---------------------------------------
Github user StefanRRichter commented on a diff in the pull request:
https://github.com/apache/flink/pull/5947#discussion_r185840213
--- Diff:
flink-end-to-end-tests/flink-datastream-allround-test/src/main/java/org/apache/flink/streaming/tests/artificialstate/eventpayload/ArtificialValueStateBuilder.java
---
@@ -33,21 +33,28 @@
private static final long serialVersionUID = -1205814329756790916L;
private transient ValueState<STATE> valueState;
+ private transient boolean afterRestoration;
private final TypeSerializer<STATE> typeSerializer;
private final JoinFunction<IN, STATE, STATE> stateValueGenerator;
+ private final RestoredStateVerifier<STATE> restoredStateVerifier;
public ArtificialValueStateBuilder(
String stateName,
JoinFunction<IN, STATE, STATE> stateValueGenerator,
- TypeSerializer<STATE> typeSerializer) {
-
+ TypeSerializer<STATE> typeSerializer,
+ RestoredStateVerifier<STATE> restoredStateVerifier) {
super(stateName);
this.typeSerializer = typeSerializer;
this.stateValueGenerator = stateValueGenerator;
+ this.restoredStateVerifier = restoredStateVerifier;
}
@Override
public void artificialStateForElement(IN event) throws Exception {
+ if (afterRestoration) {
--- End diff --
I find this way of checking the state rather invasive not completely
thorough. There is now a pretty tight coupling between creating artificial
state and checking something about it on restore. In particular, there is a
hardcoded way now when to check. This makes it harder to reuse the classes in
further test jobs that we might want to build with them. Can't we use a way
that is more based on composition? For example, wrap the state builder in a
state checker? This is also only doing just one check, so if the input element
has a key that we never encountered, the state is `null` and there might be no
check.
> End-to-end test: Job upgrade
> ----------------------------
>
> Key: FLINK-8978
> URL: https://issues.apache.org/jira/browse/FLINK-8978
> Project: Flink
> Issue Type: Sub-task
> Components: Tests
> Affects Versions: 1.5.0
> Reporter: Till Rohrmann
> Assignee: Andrey Zagrebin
> Priority: Blocker
> Fix For: 1.6.0, 1.5.1
>
>
> Job upgrades usually happen during the lifetime of a real world Flink job.
> Therefore, we should add an end-to-end test which exactly covers this
> scenario. I suggest to do the follwoing:
> # run the general purpose testing job FLINK-8971
> # take a savepoint
> # Modify the job by introducing a new operator and changing the order of
> others
> # Resume the modified job from the savepoint
> # Verify that everything went correctly
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
