The PR is merged, so everything should be back to normal.
Thanks everyone involved!
Also based on the discussion here, I have updated the FLIP-372 [1]. I tried
to incorporate every comment, but in some cases they were contradictory, so
please share your opinion on the corresponding thread [2].
Thanks Peter and Marton for the quick response and fix, I’ve left +1 for this
PR.
I’d like to take a look at followup FLIP-372 as well.
Best,
Leonard
> 2023年12月12日 上午7:39，Becket Qin 写道：
>
> Hi Peter,
>
> Thanks for updating the patch. The latest patch looks good to me. I've +1ed
> on the
Hi Peter,
Thanks for updating the patch. The latest patch looks good to me. I've +1ed
on the PR.
Cheers,
Jiangjie (Becket) Qin
On Mon, Dec 11, 2023 at 9:21 PM Péter Váry
wrote:
> Thanks everyone for the lively discussion!
>
> The PR is available which strictly adheres the accepted changes
Thanks everyone for the lively discussion!
The PR is available which strictly adheres the accepted changes from
FLIP-371. Thanks Gyula and Marton for the review. Becket, if you have any
questions left, please let me know, so I can fix and we can merge the
changes.
I would like to invite everyone
Thanks, Peter. Given the discussion I also agree that the consensus is to
move towards the mixin interface approach (and accept its disadvantages
given its advantages).
+1 for the general direction of your proposed code change in
https://github.com/apache/flink/pull/23876.
On Tue, Dec 5, 2023 at
It seems to me we have a consensus to move forward with the mixin approach.
I hope that everyone is aware that with the mixin interfaces we lose the
opportunity of the strong type checks. This will be especially painful for
generic types, where we will not have a way to ensure that the generic
Thanks Martijn for driving this!
I'm +1 to reverting the breaking change.
> For new functionality or changes we can make easily, we should switch to
the decorative/mixin interface approach used successfully in the source and
table interfaces.
I like the way of switching to mixin interface.
I am with Gyula about fixing the current SinkV2 API.
A SinkV3 seems not necessary because we are not changing the fundamental
design of the API. Hopefully we can modify the interface structure a little
bit to make it similar to the Source while still keep the backwards
compatibility.
For example,
Hi All!
Based on the discussion above, I feel that the most reasonable approach
from both developers and users perspective at this point is what Becket
lists as Option 1:
Revert the naming change to the backward compatible version and accept that
the names are not perfect (treat it as legacy).
Thanks Becket for your reply!
*On Option 1:*
- I personally consider API inconsistencies more important, since they will
remain with us "forever", but this is up to the community. I can implement
whichever solution we decide upon.
*Option 2:*
- I don't think this specific issue merits a rewrite,
Hi folks,
Sorry for replying late on the thread.
For this particular FLIP, I see two solutions:
Option 1:
1. On top of the the current status, rename
*org.apache.flink.api.connector.sink2.InitContext *to
*CommonInitContext (*should
probably be package private*)*.
2. Change the name
Thanks, Martijn and Peter.
In terms of the concrete issue:
- I am following up with the author of FLIP-321 [1] (Becket) to update
the docs [2] to reflect the right state.
- I see two reasonable approaches in terms of proceeding with the
specific changeset:
1. We allow the
I think we should try to separate the discussion in a few different topics:
- Concrete issue
- How to solve this problem in 1.19 and wrt the affected createWriter
interface
- Update the documentation [1], so FLIP-321 is visible for every
contributor
- Generic issue
Hi all,
I'm opening this discussion thread to bring a discussion that's
happening on a completed Jira ticket back to the mailing list [1]
In summary:
* There was a discussion and a vote on FLIP-371 [2]
* During implementation, it was determined that there's a diamond
inheritance problem on the
14 matches
Mail list logo
