CryoThrust commented on issue #12753: URL: https://github.com/apache/seatunnel/issues/12753#issuecomment-6142486038
One boundary detail for the string option: `-2^127` is `-170141183460469231731687303715884105728`, which needs **40 characters including the minus sign**. `DECIMAL(39,0)` is enough because decimal precision excludes the sign; a bounded VARCHAR fallback needs 40, not 39. The existing `MAX_DORIS_LARGEINT_TO_VARCHAR_LENGTH = 39` comment also misses that sign, so it should not be reused as the fallback width unchanged. I checked the converters on `dev` at `b0f6feddf`. The Oracle path answers part of the open downstream question: `OracleTypeConverter.reconvert()` clamps precision above 38 and adjusts scale, so `DECIMAL(39,0)` becomes `NUMBER(38,0)`. It therefore still cannot represent the full LARGEINT range. The Doris scalar path preserves the original `sourceType = LARGEINT`, as you noted. For the numeric fix, it would help to keep the source-schema correction separate from a promise of lossless conversion to every sink. Boundary coverage should include both signed extrema and the `ARRAY<largeint>` element precision; any bounded string fallback should check the negative extremum as well. Happy to review your patch once the mapping is agreed. This is source and numeric-boundary verification, not another live Doris/Oracle reproduction. -- 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]
