rangareddy commented on issue #17261: URL: https://github.com/apache/hudi/issues/17261#issuecomment-5365807515
This issue was reviewed as part of the JIRA-migrated backlog triage (HUDI-7843). **Findings: the machinery this ticket wants to delegate to now exists; the residual scope needs restating.** When this was filed, the transaction-time versus event-time decision for log-block partial updates lived inside `HoodieSparkRecordMerger`. Since then the merge-mode layer has been built out and is partial-update aware: `hudi-common/src/main/java/org/apache/hudi/common/table/read/BufferedRecordMergerFactory` provides distinct `COMMIT_TIME_ORDERING` and `EVENT_TIME_ORDERING` mergers, each with a "and partial update mode" variant, and callers thread `isPartialMergeEnabled` / `partialUpdateModeOpt` through (visible for example in `CDCFileGroupIterator.scala:105-106`). So the destination the ticket describes - merge mode controlling how partial updates merge - is largely in place as infrastructure. What I could not establish from reading is whether `HoodieSparkRecordMerger` still carries its own ordering decision on the Spark SQL `MERGE INTO` path, which is the specific coupling this ticket exists to remove. That determines whether anything is left to do here. Could the assignee restate the remaining delta against the current `BufferedRecordMerger` design? Given it is marked blocker, knowing whether this is done, half done, or superseded matters for release scoping. Keeping this open pending that. -- 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]
