nanjeshramesh opened a new pull request, #19945: URL: https://github.com/apache/hudi/pull/19945
### Describe the issue this Pull Request addresses Closes #14753. PR #2431 added support for using Spark SQL's `partitionBy()` clause with `TimestampBasedKeyGenerator`, and minimal tests were added to `TestCOWDataSource` for it, but the issue asks for more coverage with respect to the timestamp based key gen than what exists there today. ### Summary and Changelog Adds `testSparkPartitionByWithTimestampBasedKeyGeneratorScalar`, covering the `SCALAR` timestamp type with an explicit `INPUT_TIME_UNIT`. This exercises a genuinely different code path in `TimestampBasedAvroKeyGenerator` than the existing `EPOCHMILLISECONDS` test right above it: `SCALAR` treats the field as a raw numeric value that needs an explicit unit to convert to a timestamp, rather than the unit being implied by the type name. `TestTimestampBasedKeyGenerator` already unit-tests `SCALAR` at the key generator layer directly, but that does not exercise the Spark DataFrame write path, config option plumbing, and partition path resolution together the way this test class does for the other timestamp types, so this closes a real gap specific to `TestCOWDataSource`. The new test mirrors the existing `testSparkPartitionByWithTimestampBasedKeyGenerator` immediately above it: same data, same assertion shape, same parameterization over AVRO/SPARK record types. Since `current_ts` is generated in epoch milliseconds, `SCALAR` with `INPUT_TIME_UNIT=MILLISECONDS` is expected to partition identically to the existing `EPOCHMILLISECONDS` test, which the assertion confirms. ### Impact None. Test-only change, no production code touched. ### Risk Level none ### Documentation Update none ### Contributor's checklist - [x] Read through [contributor's guide](https://hudi.apache.org/contribute/how-to-contribute) - [x] Enough context is provided in the sections above - [x] 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]
