wombatu-kun opened a new pull request, #19335:
URL: https://github.com/apache/hudi/pull/19335

   ### Describe the issue this Pull Request addresses
   
   When syncing a table in HMS mode, `HMSDDLExecutor.createTable` sets the Hive 
`createTime` with `newTb.setCreateTime((int) System.currentTimeMillis())`. Hive 
stores `createTime` as seconds since the epoch in an `i32` field, but this 
passes raw milliseconds: the value is 1000x too large and, being ~1.7e12, 
overflows the `int` cast into a garbage (often negative or far-past) value. The 
rest of the codebase already does this correctly, for example 
`HoodieHiveCatalog` uses `(int) (System.currentTimeMillis() / 1000)`.
   
   ### Summary and Changelog
   
   Divides the millisecond timestamp by 1000 before the `int` cast so the Hive 
metastore records the table's creation time as epoch seconds, matching Hive's 
contract and the existing `HoodieHiveCatalog` usage.
   
   - `HMSDDLExecutor.createTable` now calls `setCreateTime((int) 
(System.currentTimeMillis() / 1000))`.
   - Adds unit test `TestHMSDDLExecutorCreateTable` that captures the `Table` 
passed to `createTable` (with a mocked `IMetaStoreClient`) and asserts 
`createTime` is epoch seconds within the call window; this assertion fails 
against the previous milliseconds value.
   
   ### Impact
   
   Tables created via HMS-mode Hive sync now record a correct `createTime` 
(visible in `DESCRIBE FORMATTED` and used by tools that read table age). No 
public API or configuration change.
   
   ### Risk Level
   
   low
   
   One-line change plus a unit test; the behavior is verified against the 
corrected value and matches the existing `HoodieHiveCatalog` convention.
   
   ### Documentation Update
   
   none
   
   ### Contributor's checklist
   
   - [ ] Read through [contributor's 
guide](https://hudi.apache.org/contribute/how-to-contribute)
   - [ ] Enough context is provided in the sections above
   - [ ] Adequate tests were added if applicable
   


-- 
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]

Reply via email to