fatmanverse commented on PR #12802: URL: https://github.com/apache/seatunnel/pull/12802#issuecomment-6547063052
Found one more problem while re-checking the EasyExcel path, fixed in bff617912. Microsoft Excel saves many numbers with 17 significant digits: `test_read_excel_formula.xlsx` (saved by Excel 16) stores `5.555` as `<v>5.5549999999999997</v>` and `6.666` as `<v>6.6660000000000004</v>`. EasyExcel's `getOriginalNumberValue()` is `new BigDecimal(<v> text)`, so on the previous head a `decimal(10, 3)` column read `5.5549999999999997` with EasyExcel, while POI (and EasyExcel before this PR) read `5.555`. DOUBLE and the integer types were not affected, since they parse the same text to the same `double`. `ExcelCellUtils#convert` now uses `Double.toString(getOriginalNumberValue().doubleValue())` for a number cell in a numeric column, the same text the POI reader gets. `0.30000000000000004` still reads back in full, and a whole-number DECIMAL now has the same scale with both engines (`10.0`), which also settles the earlier note about `10` vs `10.0`. - New `ExcelReadStrategyTest#testExcelWrittenNumberReadsAsTypedValue` reads that file with POI and EasyExcel and expects `5.555` / `6.666`. On the previous head it failed for EasyExcel only: `expected: <5.555> but was: <5.5549999999999997>`. - The en/zh `incompatible-changes.md` entry now describes the read and write rule as "the shortest decimal text of the `double`" instead of "a `double` holds it exactly", which was not what the code checks (`0.1` is written as a number cell). - Verified on JDK 17 against the latest `dev` (f3e1c2ee3): `connector-file-base` unit tests 387 run, 0 failures; `LocalFileIT#testLocalFileExcel` 6/6. I also updated the PR description to match. -- 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]
