Hi Hangxiang, Thanks for driving this. It is reasonable to let the new serializer claim its compatibility with the old serializer. However, I think there is a little confusion as you described in your proposed change 'Step 1'. You mean that we let the new serializer check the compatibility first, and if it gives the 'INCOMPATIBLE' then we let the old serializer do the check as before. The 'INCOMPATIBLE' from the new serializer means 'do not know' or 'unresolved' here, but sometimes the new serializer should express a decisive meaning that it is really not compatible with the older one, which is the 'INCOMPATIBLE' should mean. There is a semantic ambiguity or missing. I think there are two options to resolve this: 1. Provide 'UNRESOLVED' in type of the compatibility checking result, and let the proposed new interface return it by default. OR 2. Replace any use of the old interface with the new interface. In the default implementation of the new interface, call the old interface to leverage the old result. This approach provides the ability to totally replace original checking logic (by implementing the new interface in new serializer) while maintaining good backward compatibility.
What do you think? Best, Zakelly. On Wed, Oct 12, 2022 at 8:41 PM Hangxiang Yu <master...@gmail.com> 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
