Github user je-ik commented on the issue:
https://github.com/apache/flink/pull/5185
@StefanRRichter I think that was exactly the initial idea, but then we came
into troubles with the savepoints and changing list type. Also as @aljoscha
mentioned, it can be confusing for users to see
Github user je-ik commented on the issue:
https://github.com/apache/flink/pull/5185
@StephanEwen I think it should be configurable. As Aljoscha pointed out, it
is needed to ensure that these two representations have the same serialized
form in checkpoints, because that way users can
Github user je-ik commented on the issue:
https://github.com/apache/flink/pull/5185
@aljoscha I updated the title. I'm a little concerned about the
serialization in savepoint. If the serialization is *exactly* the same, doesn't
that actually mean that again, the whole List
Github user je-ik commented on the issue:
https://github.com/apache/flink/pull/5185
@aljoscha I (partly) reworked this PR as you suggest. There are still some
unresolved questions though:
1) I'm not 100% sure how to cleanly support the migration between list
state savepoints
Github user je-ik commented on the issue:
https://github.com/apache/flink/pull/5185
I think that the failed test is not related to this PR.
---
GitHub user je-ik opened a pull request:
https://github.com/apache/flink/pull/5185
[FLINK-8297] [flink-rocksdb] optionally use RocksDBMapState internally for
storing lists
## What is the purpose of the change
Enable storing lists not fitting to memory per single key
