Hi Hangxiang, Thanks for the proposal. It seems more reasonable to let the new serializer claim the compatibility in the cases you mentioned.
I have but one question here. What happens in the case of “compatibleAfterMigration” after we completely reverse the direction (in step 3)? To be specific, migration from an old schema calls for the previous serializer to read bytes into state objects. How should a new serializer decide whether the migration is possible? Best, Han On 2022/10/12 12:41:07 Hangxiang Yu wrote: > Dear Flink developers, > > I would like to start a discussion thread on FLIP-263[1] proposing to > improve the usability of resolving schema compatibility. > > Currently, the place for compatibility checks is > TypeSerializerSnapshot#resolveSchemaCompatibility > which belongs to the old serializer, There are no ways for users to specify > the > compatibility with the old serializer in the new customized serializer. > > The FLIP hopes to reverse the direction of resolving schema compatibility > to improve the usability of resolving schema compatibility. > > [1] > https://cwiki.apache.org/confluence/display/FLINK/FLIP-263%3A+Improve+resolving+schema+compatibility >
