DanielLeens commented on PR #12853: URL: https://github.com/apache/seatunnel/pull/12853#issuecomment-6266155502
Quick follow-up to close out the one open item from my review: **the `Build` workflow has now completed successfully on the current head `dad4e1244`**, so my earlier "waiting for the required Build workflow" note no longer applies. That matches what @zhengxiang378928908-code reported just above — an end-to-end Zeta local run against MySQL 8.0 → PostgreSQL 16 producing `numeric(65,0)` / `numeric(50,30)` with exact round-trip, versus `numeric field overflow` or silent scale-18 rounding on `dev`. That's strong evidence for the converter change itself. Recapping where I land, all on the current head: - **Source side:** no blockers from my review. The converter keeps the declared precision/scale up to the MySQL limit, clamps over-limit precision by shrinking scale first, and the wide-`DecimalType` flow into downstream engines is covered by the EN/ZH incompatible-changes entry plus the migration note. - **CI side:** green. - **Remaining gate:** `mergeStateStatus` is `BLOCKED` only because a qualifying write-level approval is still missing — there is no technical item left on my side. Two non-blocking suggestions from @zhengxiang378928908-code (a non-MySQL target in the tests, and the incompatible-changes wording) are worth a look, but neither is a merge blocker and both would be perfectly reasonable follow-ups. Thanks @Eymenonar for the careful work here — the DECIMAL precision area has been a long-standing rough edge in the MySQL/OceanBase converters, and this is a clean fix. -- 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]
