anyone has any question about this discussion? I'm looking forwards to
> your feedback.
>
>
>
> Best regards,
> tanjialiang.
>
>
> Replied Message
> | From | tanjialiang |
> | Date | 4/13/2023 10:05 |
> | To | dev@flink.apache.org |
> | Subj
Hi, devs.
Do anyone has any question about this discussion? I'm looking forwards to your
feedback.
Best regards,
tanjialiang.
Replied Message
| From | tanjialiang |
| Date | 4/13/2023 10:05 |
| To | dev@flink.apache.org |
| Subject | [DISCUSS] EncodingFormat and DecondingF
Hi, Aitozi,
Thanks you for your feedback, and +1 for your point of view.
Best,
tanjialiang.
Replied Message
| From | Aitozi |
| Date | 4/14/2023 16:19 |
| To | |
| Subject | Re: [DISCUSS] EncodingFormat and DecondingFormat provide copy API |
Hi tanjialiang
Thanks for reporting this, I
Hi tanjialiang
Thanks for reporting this, I think it's a reasonable requirements.
The problem might be introduced during the optimization when
reusing the mutable state in Source. So the DecodingFormat#copy can
avoid this situation.
But after checking the related code for DynamicTableSink,
Hi, devs.
I'd like to start a discussion about to EncodingFormat and DecondingFormat
provide copy API, which relate to FLINK-31686 [1].
Current, DecodingFormat doesn't support copy(), which makes the DecodingFormat
resued after filter/projection is pushed down. The EncodingFormat has the sam
