gt; > proposal also looks good to me.
> > Thanks Hangxiang for driving this.
> > Best,
> > Yun Gao
> > --
> > From:Yuan Mei
> > Send Time:2022 Oct. 26 (Wed.) 12:20
> > To:dev
> > Subject
:2022 Oct. 26 (Wed.) 12:20
To:dev
Subject:Re: [DISCUSS] FLIP-263: Improve resolving schema compatibility
Hey Huangxiang,
The section of `Rejected Alternatives` may also need an update.
Current plan sounds like a reasonable one. I am fine with it.
Thanks for driving this.
Best
Yuan
On Tue, Oct 25
] FLIP-263: Improve resolving schema compatibility
Hey Huangxiang,
The section of `Rejected Alternatives` may also need an update.
Current plan sounds like a reasonable one. I am fine with it.
Thanks for driving this.
Best
Yuan
On Tue, Oct 25, 2022 at 5:11 PM Hangxiang Yu wrote:
> （Resend the m
Hey Huangxiang,
The section of `Rejected Alternatives` may also need an update.
Current plan sounds like a reasonable one. I am fine with it.
Thanks for driving this.
Best
Yuan
On Tue, Oct 25, 2022 at 5:11 PM Hangxiang Yu wrote:
> （Resend the mail to fix the format issue）
> Hi, everyone.
>
（Resend the mail to fix the format issue）
Hi, everyone.
Thanks for your suggestions!
Let me summarize the remaining questions in the thread and share my ideas
based on your suggestions:
1. Should we put the new opposite interface in TypeSerializer or
TypeSerializerSnapshot ?
Just as I
Hi, everyone.
Thanks for your suggestions!
Let me summarize the remaining questions in the thread and share my ideas
based on your suggestions:
1. Should we put the new opposite interface in TypeSerializer or
TypeSerializerSnapshot ?
Just as I replied to Dawid, I'd like to put it in
Hey Hangxiang,
Thanks for driving this issue. I've read through all the discussions and
suggestions in this thread, and here is my take:
1. I agree that the compatibility check should be done in the opposite
direction.
The current interface *causes some real issues* for users using their
own
Hi Hangxiang, Dawid,
I also prefer to add method into TypeSerializerSnapshot, which looks
more natural. TypeSerializerSnapshot has `Version` concept, which also
can be used for compatibility.
`
TypeSerializerSnapshot {
TypeSerializerSchemaCompatibility resolveSchemaCompatibility(
That's the final status we will arrive at.
IIUC, we cannot just remove the original method but just mark it as
deprecated so two methods have to exist together in the short term.
Users may also need to migrate their own external serializers which
is a long run.
I'd like to
Hi, Dawid.
Thanks for your reply.
Should we introduce the new method to the TypeSerializerSnapshot instead?
You provided a valuable option, let me try to list the benefit and cost.
benefit:
1. TypeSerializerSnapshot still owns the responsibility of resolving
schema compatibility so
Hi Han,
I think in principle your proposal makes sense and the compatibility
check indeed should be done in the opposite direction.
However, I have two suggestions:
1. Should we introduce the new method to the TypeSerializerSnapshot
instead? E.g.
TypeSerializerSnapshot {
Hi, Zakelly.
Good point. +1 it makes code more straightforward.
I have modified the FLIP to make the new interface call the old interface
as default.
On Fri, Oct 14, 2022 at 4:46 PM Zakelly Lan wrote:
> Hi Hangxiang,
>
> I'm ok with your proposed Step 2, but I'm afraid you missed my point.
>
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
Hi Hangxiang,
I'm ok with your proposed Step 2, but I'm afraid you missed my point.
As I described in the option 2, it is unnecessary to call the new and
old interface both. Instead of that, replace any use of the old
interface with the new interface, and call the old interface in the
default
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
Hi, Zakelly.
Thanks for your suggestion and I think it makes sense.
I think both two options should be adopted. The option 2 is just what I
mentioned in step 2. At the same time, we still need option 1 because we
should make sure the existing user code could run normally without
modifying any
Hi Hangxiang,
Thanks for raising the discussion, +1 for reversing the direction of
resolving schema compatibility.
As you described, in 'Step 1', Typeserializer#resolveSchemaCompatibility
will return TYPE.INCOMPATIBLE default,
Typeserializer#resolveSchemaCompatibility is a default method; in
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,
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
19 matches
Mail list logo
