Hi Martijn, I went through the implementation and the discussion. The in-place migration to a writer-only Sink V2 looks reasonable to me, and I have no additional concerns beyond the compatibility points already raised.
Please make sure the release notes clearly describe the affected savepoint-restore scenarios and the upgrade/rollback expectations, so existing users can assess the impact before upgrading. Thanks for driving this migration! Best regards, Yanquan Martijn Visser <[email protected]> 于2026年10月23日周五 15:31写道： > Hi all, > > FLIP-239 [1], voted in October 2023, specified a separate > JdbcDynamicTableSinkV2 next to the existing JDBC table sink, with a > deprecation window before the SinkFunction-based one is removed. The > DataStream side of the FLIP is done. The table sink is the last legacy > Flink API in the connector, and SinkFunctionProvider has been @Internal and > deprecated since Flink 2.0 (FLINK-36245). > > I want to deviate from the FLIP in two places and would like to hear > objections. If there are no objections raised in the next 10 days, I assume > that people are OK with this. There is already a draft PR available [2]. > > 1. In place, not a V2 class. Today JdbcDynamicTableSink returns a > SinkFunctionProvider over GenericJdbcSinkFunction. With this change it > returns an internal, writer-only Sink<RowData> under the existing factory. > That sink wraps JdbcWriter, the writer of the DataStream JdbcSink, and has > no committer and no writer state. The SQL connector has no XA mode, so the > XA path is not involved. With a primary key it keeps writing upserts, which > makes a replay after a failure idempotent. The DataStream JdbcSink is > untouched. > > 2. No deprecation window. There is nothing for a user to migrate: same > identifier, same options, same changelog semantics, and the writer > registers no state, so jobs with operator uids restore their savepoints in > both directions. The PR has a test for the upgrade direction. The sink task > is renamed "<sink>: Writer" and the standard writer metrics appear: > numRecordsSend counts the records added to the JDBC batch, and numBytesSend > stays at zero. A statement set without uids in which a JDBC sink receives a > rowtime column cannot restore an older savepoint, because the planner puts > a timestamp inserter in front of every Sink V2 sink. We'd include that in > the release notes. > > I will also update the FLIP page, which still carries the discussion label > and no release. > > Best regards, > > Martijn > > [1] > > https://cwiki.apache.org/confluence/display/FLINK/FLIP-239%3A+Port+JDBC+Connector+to+FLIP-27%26FLIP-143 > [2] https://github.com/apache/flink-connector-jdbc/pull/254 >
