SEZ9 commented on issue #12841: URL: https://github.com/apache/seatunnel/issues/12841#issuecomment-6258087538
@zhengxiang378928908-code thanks for the correction — that framing is right: a `DECIMAL(65, 0)` column holding 30 integer digits cannot survive the remap to `DECIMAL(38, 18)`, which only leaves 20 integer digits, and `DECIMAL(50, 30)` loses fractional capacity for the same reason. Agreed that approach A (preserving the declared precision/scale for signed DECIMAL up to MySQL's limits) is the one to pursue, and agreed that B does not address the `DECIMAL(50, 30)` case. Coordination sounds good: @Eymenonar takes the MySQL-only fix, and your help with review plus the end-to-end reproduction would be very useful — in particular a MySQL -> MySQL run with auto-created sink tables for both `DECIMAL(65, 0)` and `DECIMAL(50, 30)` so we can confirm the DDL and values round-trip. @Eymenonar, for the PR please make sure it: - preserves declared precision and scale for signed DECIMAL above 38 instead of clamping to `DECIMAL(38, 18)`; - states the intended rule for unsigned DECIMAL explicitly so signed and unsigned paths are consistent; - covers source schema conversion and generated MySQL sink DDL for `DECIMAL(65, 0)` and `DECIMAL(50, 30)` with tests; - keeps OceanBase and GenericTypeConverter out of scope unless their tests show the same clamping; - documents the observable schema-compatibility change for users relying on the current `DECIMAL(38, 18)` output. Please link the PR here once it is up so we can track it against this issue. <!-- streview-comment:1853 --> -- 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]
