Hi, yes, the assumption is correct. This is no instability, but actually stopping the user to corrupt data through attempting an unsupported operation. Migration required is the outcome of the compatibility check that would start a migration process. For Avro, the serializer does not have to signal this result, because the serialize itself can deal with all versions at all times. It can simply signal that it is compatible.
Best, Stefan > Am 11.08.2017 um 13:57 schrieb Biplob Biswas <revolutioni...@gmail.com>: > > Hi Stefan, > > Thanks a lot for such a helpful response. That really made thing a lot > clearer for me. Although at this point I have one more and probably last > question. > > According to the Flink documentation, > > [Attention] Currently, as of Flink 1.3, if the result of the compatibility > check acknowledges that state migration needs to be performed, the job > simply fails to restore from the checkpoint as state migration is currently > not available. The ability to migrate state will be introduced in future > releases. > > Now if I end up using AvroSerialization with RocksDB, I am assuming state > migration wouldn't be needed as the Avro serializer should automatically be > compatible with the older versions as well and thus my job wouldn't be > affected by this inability for state migrations. > > Does my assumption sound correct? Can I expect this behaviour? > > Thanks a lot. > > Best, > Biplob > > > > -- > View this message in context: > http://apache-flink-user-mailing-list-archive.2336050.n4.nabble.com/Evolving-serializers-and-impact-on-flink-managed-states-tp14777p14830.html > Sent from the Apache Flink User Mailing List archive. mailing list archive at > Nabble.com.
