rangareddy commented on issue #17222: URL: https://github.com/apache/hudi/issues/17222#issuecomment-5366110156
This issue was reviewed as part of the JIRA-migrated backlog triage (HUDI-4091). **Findings: needs a reproduction against a current build before it can be dispositioned.** The report is concrete: timestamps written with spark.sql.parquet.outputTimestampType=TIMESTAMP_MICROS and hoodie.parquet.outputtimestamptype=TIMESTAMP_MICROS come back at millisecond precision on read. Reproducing it looks tractable - a small write-then-read round trip with a microsecond-precision timestamp is enough; no cluster needed. I have not called this from the source. The surrounding code has been rewritten substantially since this was filed - table versions 8 and 9, the `BufferedRecordMerger` family replacing payload-based merging, the file-group-reader migration, the indexer abstraction in #18348 / #18372, and the `hudi-common` package moves in #19193 / #19195. Inferring either "still broken" or "silently fixed" through that much churn would be a guess. There is also no commit anywhere in the tree referencing HUDI-4091, so if it was fixed it was incidental rather than deliberate - another reason to verify rather than assume. This is one of four timestamp-precision reports in the backlog and they should be triaged as a set rather than individually: #17302 (HUDI-8592, `hoodie.parquet.outputtimestamptype=TIMESTAMP_MILLIS` ignored, parquet always micros), #17247 (HUDI-7306, CustomKeyGenerator dropping the microseconds part), #17329 (HUDI-8677, Hive truncating micros to millis), and this one. They may share a single root cause in how the output timestamp type is threaded from Hudi options into the parquet writer - and note #17302 reports the opposite symptom to this ticket, which is itself informative. Keeping this open. -- 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]
