JingsongLi commented on PR #10200: URL: https://github.com/apache/paimon/pull/10200#issuecomment-5950614669
Closing this iteration because the current diff does not deliver the end-to-end behavior described in the title/body or resolve #10099. At head `3e5f159913`, the only change is the `TimeType` Javadoc. `MAX_PRECISION` is still 9, and the precision check, string conversion, serializer, and file-format paths are unchanged. The documentation clarifies the storage limitation, but the reported silent precision loss remains. I verified the current head through a real Java API round trip: create a TIME(7) table, convert the input with `DateTimeUtils.parseTime`, write and commit to Parquet, then reopen and read the table: - `new TimeType(7)` and `new TimeType(9)` both succeed. - `12:34:56.1234567` reads back as `12:34:56.123`. - `12:34:56.1235567` reads back as `12:34:56.124`. - Neither conversion nor writing reports the loss. The underlying issue is worth fixing. A focused follow-up should provide an explicit policy/diagnostic at the conversion boundary and test that caller-visible outcome. Globally rejecting TIME(4..9) would also break established schema/CDC contracts, so that needs a compatibility decision rather than a documentation-only substitute. Widening the persisted representation would require separate format/migration work. Please keep #10099 open for that behavioral fix. This closure follows the review criterion of requiring an actual end-to-end improvement; it is not a claim that the reported issue is invalid. Validation: the actual Parquet round-trip probe passes while reproducing the remaining loss; all 55 existing DataTypesTest, DateTimeUtilsTest and SchemaMergingUtilsTest cases pass with normal Maven checks. -- 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]
