li3zhi4 commented on PR #11746: URL: https://github.com/apache/seatunnel/pull/11746#issuecomment-6214411521
@SEZ9 — evidence part 2/2 (F5–F8), same head `e7586c06a83ae174775bd3fdd8aa46a05039672f`. - **F5 — comma separator:** an intentional **display/metadata naming limitation**, not a tuple codec or a new rejection rule. [Javadoc](https://github.com/apache/seatunnel/blob/e7586c06a83ae174775bd3fdd8aa46a05039672f/seatunnel-connectors-v2/connector-jdbc/src/main/java/org/apache/seatunnel/connectors/seatunnel/jdbc/source/DynamicChunkSplitter.java#L117-L124) states that comma-containing identifiers produce an ambiguous joined name. [split construction](https://github.com/apache/seatunnel/blob/e7586c06a83ae174775bd3fdd8aa46a05039672f/seatunnel-connectors-v2/connector-jdbc/src/main/java/org/apache/seatunnel/connectors/seatunnel/jdbc/source/DynamicChunkSplitter.java#L177-L191) carries the key type/names and boundary arrays structurally; values are not encoded in the joined display name, and there is no separator decoding. The MySQL regression linked in part 1 includes a comma-containing value. This does **not** claim an escaping codec or dedicated comma-identifier regression was a dded. - **F6 — numeric comparison:** [element/numeric comparison](https://github.com/apache/seatunnel/blob/e7586c06a83ae174775bd3fdd8aa46a05039672f/seatunnel-connectors-v2/connector-jdbc/src/main/java/org/apache/seatunnel/connectors/seatunnel/jdbc/source/DynamicChunkSplitter.java#L432-L475) normalizes finite Numbers via `BigDecimal.compareTo`; the [duplicate-boundary guard](https://github.com/apache/seatunnel/blob/e7586c06a83ae174775bd3fdd8aa46a05039672f/seatunnel-connectors-v2/connector-jdbc/src/main/java/org/apache/seatunnel/connectors/seatunnel/jdbc/source/DynamicChunkSplitter.java#L161-L169) uses `compareArrays(...) == 0`, not `Arrays.equals`. [regression](https://github.com/apache/seatunnel/blob/e7586c06a83ae174775bd3fdd8aa46a05039672f/seatunnel-connectors-v2/connector-jdbc/src/test/java/org/apache/seatunnel/connectors/seatunnel/jdbc/source/CompositeKeyChunkSplitterTest.java#L584-L605) checks Integer/Long mixing and `BigDecimal("1.0")` vs `BigDecimal("1.00")`. - **F7 — upgrade and opt-out:** [EN](https://github.com/apache/seatunnel/blob/e7586c06a83ae174775bd3fdd8aa46a05039672f/docs/en/connectors/source/Jdbc.md#L303-L313) / [ZH](https://github.com/apache/seatunnel/blob/e7586c06a83ae174775bd3fdd8aa46a05039672f/docs/zh/connectors/source/Jdbc.md#L299-L309) explicitly document changed boundaries, single-column `partition_column` opt-out and full-table `enable_concurrent_read=false`; [EN incompatible change](https://github.com/apache/seatunnel/blob/e7586c06a83ae174775bd3fdd8aa46a05039672f/docs/en/introduction/concepts/incompatible-changes.md#L150-L155) / [ZH incompatible change](https://github.com/apache/seatunnel/blob/e7586c06a83ae174775bd3fdd8aa46a05039672f/docs/zh/introduction/concepts/incompatible-changes.md#L93-L98) are retained. [partition-column regression](https://github.com/apache/seatunnel/blob/e7586c06a83ae174775bd3fdd8aa46a05039672f/seatunnel-connectors-v2/connector-jdbc/src/test/java/org/apache/seatunnel/connectors/seatunnel/jd bc/source/CompositeKeyChunkSplitterTest.java#L718-L755) verifies the single-key override. - **F8 — fixed splitter:** the [dynamic-only discovery gate](https://github.com/apache/seatunnel/blob/e7586c06a83ae174775bd3fdd8aa46a05039672f/seatunnel-connectors-v2/connector-jdbc/src/main/java/org/apache/seatunnel/connectors/seatunnel/jdbc/source/ChunkSplitter.java#L445-L447) prevents composite-key discovery in the fixed path, and [defensive rejection](https://github.com/apache/seatunnel/blob/e7586c06a83ae174775bd3fdd8aa46a05039672f/seatunnel-connectors-v2/connector-jdbc/src/main/java/org/apache/seatunnel/connectors/seatunnel/jdbc/source/FixedChunkSplitter.java#L62-L76) rejects multi-column keys. [both regressions](https://github.com/apache/seatunnel/blob/e7586c06a83ae174775bd3fdd8aa46a05039672f/seatunnel-connectors-v2/connector-jdbc/src/test/java/org/apache/seatunnel/connectors/seatunnel/jdbc/source/CompositeKeyChunkSplitterTest.java#L758-L811) cover discovery and rejection. **Oracle status / exact ordering:** the [fork run](https://github.com/li3zhi4/seatunnel/actions/runs/38544126048) is completed/success (attempt 2) on this SHA, and the [apache Build](https://github.com/apache/seatunnel/runs/116235056139) is success. Daniel's [CI-log update](https://github.com/apache/seatunnel/pull/11746#issuecomment-6190326900) reports OracleSplitIT 3/3 on both JDK lanes. I have independently checked the API run/check results, but have not completed an independent raw-log download. In particular, the SQL Server **SplitIT → IT** ordering described there is not evidence for **IT teardown → SplitIT**. Nor am I claiming that green Build alone proves the requested Oracle order. The retained local alphabetical reports specify `JdbcOracleIT,JdbcOracleSplitIT`: **JdbcOracleIT has a container-startup error; JdbcOracleSplitIT is 3/3 passed**. Therefore they are not a fully green ordered acceptance. A fresh official `-Dfailsafe.runOrder=alphabetical -Dit.test=JdbcOracleIT,JdbcOracleSplitIT` run is now in progress; I will report its actual class order and both results, not substitute a standalone/reverse-order run. To restore the complete sentence from my earlier message: **I did not change the Oracle image version or weaken assertions to hide the readiness timeout.** No new source change is proposed for F1–F8. Could you confirm which of these existing implementations satisfy your items, especially whether F5's stated naming limitation is acceptable? The specified Oracle ordered acceptance remains explicitly outstanding until the fresh run completes. -- 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]
