rangareddy commented on issue #17372: URL: https://github.com/apache/hudi/issues/17372#issuecomment-5351240092
This issue was reviewed as part of the JIRA-migrated backlog triage (HUDI-8915). **Findings: needs a reproduction on current `master`; I am not going to call it from code.** The scenario is crisp enough to test directly - a COW table holding `(id 1, ts 100)`, then a `MERGE INTO` delete carrying `(id 1, ts 99)`, which should be a no-op under event-time ordering. What I can say is that the read-side merge machinery does treat deletes as ordering-sensitive. `hudi-common/src/main/java/org/apache/hudi/common/table/read/BufferedRecordMergerFactory.java` has a distinct `EVENT_TIME_ORDERING` merger whose delete path at `:196-197` delegates to `deltaMergeDeleteRecord(...)` (`:488`), separate from the `COMMIT_TIME_ORDERING` merger's delete handling at `:114`. That is not the same as proving the COW `MERGE INTO` **write** path routes a delete through it, which is the actual claim here. And the area has been reworked substantially since this was filed - table versions 8 and 9, and the `BufferedRecordMerger` family replacing payload-based merging - so inferring a verdict either way would be a guess rather than a finding. The repro is two statements; running it on 1.2.x for a COW table with event-time ordering configured would settle it. Worth also checking the MOR equivalent in the same pass, since the ticket scopes itself to COW and it would be useful to know whether that scoping still holds. 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]
