zhang-arvin opened a new pull request, #10200: URL: https://github.com/apache/paimon/pull/10200
## Purpose Fixes #10099. A `TIME` value is stored as milliseconds of the day in an `int` at every layer - the internal row representation, `RowCompactedSerializer` and the Parquet `TIME_MILLIS` logical type - so at most 3 fractional digits are representable. `TimeType` nonetheless declared `MAX_PRECISION = 9` and its Javadoc advertised nanosecond precision via a `long`. As a result a declaration like `TIME(7)` - which is what an MSSQL `TIME(7)` column maps to - was accepted and then silently narrowed to milliseconds, with rounding: `DateTimeUtils.parseFraction` rounds on the 4th fractional digit, so `12:34:56.1234567` was written back as `12:34:56.124`, i.e. larger than the input, with no error. This caps the declared precision at what is actually representable so the declaration fails fast, and corrects the Javadoc that promised the nanosecond range. Widening the storage format was deliberately not attempted: it would change the row serialization and Parquet type for existing tables. ### Tests - `DataTypesTest#testTimeTypeRejectsUnrepresentablePrecision` asserts `TIME(7)` and `TIME(9)` are rejected at declaration. - Updated `SchemaMergingUtilsTest#testMergeTypesWithPrecision`, which constructed `TimeType(6)`/`TimeType(9)` for its equal-precision and lower-precision cases. `mvn -pl paimon-common -Pfast-build -Dtest=DataTypesTest test` -> 27 tests, 0 failures. `mvn -pl paimon-core -Pfast-build -Dtest=SchemaMergingUtilsTest test` -> 17 tests, 0 failures. -- 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]
