yihua opened a new pull request, #19990: URL: https://github.com/apache/hudi/pull/19990
### Describe the issue this Pull Request addresses closes #19989 `HoodieRecordUtils.createHoodieRecord` picks a payload-carrying `HoodieAvroRecord` or a payload-free `HoodieAvroIndexedRecord` based on a subclass test of the configured merge handle against `FileGroupReaderBasedMergeHandle`. That test misclassifies payload-free handles that do not extend it, reads a config that `HoodieMergeHandleFactory` overrides in most branches, and is evaluated once on the driver while the handle is chosen per file group with a runtime fallback. The two representations source their ordering value differently, so the same record can serve the payload's `Integer` default instead of its ordering field depending only on which handle is configured. ### Summary and Changelog The representation is now decided by `isPayloadClassDeprecated(payloadClass)` alone. `requiresPayload` is removed from every `createHoodieRecord` overload and `HoodieWriteConfig.isFileGroupReaderBasedMergeHandle` is deleted. Callers in `HoodieCreateRecordUtils`, `HoodieStreamerUtils`, `HoodieIndexUtils`, `AvroRecordContext` and `SparkFullBootstrapDataProviderBase` are updated; every one outside the Spark write path and the streamer already passed a literal `false`. The create-handle benchmark moves to the seven-argument overload because dropping the parameter left two five-argument overloads that Scala cannot disambiguate for a primitive ordering value. ### Impact No public API change. With the default `FileGroupReaderBasedMergeHandle` this is a no-op: that configuration already took the payload-free branch. Behaviour changes only for a configured non-FileGroupReader merge handle combined with one of the nine classes in `DEPRECATED_PAYLOADS`; those records become `HoodieAvroIndexedRecord`, re-derive the ordering value from the record data, and detect deletes through `DeleteContext` rather than only the is-deleted meta column. Payload classes outside the nine are unchanged. ### Risk Level low. The default configuration is unaffected. Every merge and append handle on the changing-records path consumes incoming records through `BufferedRecords.fromHoodieRecord` or an equivalent abstraction and never calls `HoodieRecordPayload` APIs on the incoming record; custom merge modes rebuild the payload from buffered data in `HoodieAvroRecordMerger`. Verification is by CI on this PR; the equivalent change on the internal 1.x line passes its full spark, client and utilities matrix, and the reviewer there ran `TestGlobalIndexEnableUpdatePartitions` with the handle pinned to `HoodieWriteMergeHandle` to force the old payload branch, 20 of 20 on base and change. ### Documentation Update None. No new config, no default value change, no user-facing feature change. ### 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 - [ ] 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]
