DanielLeens commented on issue #11742: URL: https://github.com/apache/seatunnel/issues/11742#issuecomment-5239944072
Thanks for writing this up so concretely. I re-checked current `dev`, and the capability gap is real on the MySQL CDC side: - `MySqlUtils.getSplitType(Table, ...)` and `getSplitColumn(Table)` still collapse a composite primary key to `primaryKeys.get(0)`. - `AbstractJdbcSourceChunkSplitter` still chooses one `Column splitColumn` and feeds that into the chunk-generation path. - The base `JdbcSourceChunkSplitter` contract is still single-column (`queryMinMax` / `queryMin` / `queryNextChunkMax` over one `Column`), so there is not yet a tuple-based base API on `dev`. So treating this as a layered CDC splitter capability gap is reasonable, not as a duplicate of the older split-column-selection bugs. The scope boundary you proposed also looks right for a first PR: keep `connector-jdbc` separate in #11741, keep other CDC dialects unchanged for now, and add only the generic base-layer surface that MySQL needs for a correct tuple-ordered implementation. For review, the most important proof points in the first Draft PR will be: - no regression for the existing single-column / no-PK / user-configured split-column paths; - half-open, non-overlapping tuple boundaries for composite keys; - SQL shape that stays index-friendly on MySQL rather than relying on a row-constructor form that may degrade plans. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
