Hi, Han. Both the old method and the new method can get previous and new inner information.
The new serializer will decide it just like the old serializer did before. The method just specify the schema compatibility result so that other behaviours is same as before. On Fri, Oct 14, 2022 at 11:40 AM Han Yin <alexyin...@gmail.com> wrote: > 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 > > -- Best, Hangxiang.
