linliu-code opened a new pull request, #680: URL: https://github.com/apache/hudi-rs/pull/680
## Description Nothing in the gold corpus made a log write lose on ordering value. Every event-time fixture either raises the ordering value on an update or leaves it alone, and a tie goes to the newer record, so the whole sweep (62 fixtures and their option cases, on both reader versions) passed unchanged when event-time ordering degraded to last-writer-wins. That semantics was asserted only by unit tests. The delete-ordering fixtures do not cover it either: they are all COMMIT_TIME_ORDERING, where the delete always applies. This adds one v9 MOR fixture carrying both shapes in both directions: an update below the live ordering value and one above it, and a delete below and one above. A delete record carries the ordering value of the source row it matched, so `MERGE INTO` is what places a delete below the live row; a plain `DELETE` takes the live row's own value and ties. Generated with Spark 3.5.3 and Hudi 1.2.0-SNAPSHOT, the same way the rest of the corpus was, so `gold_data` is Hudi's own answer rather than ours. Follow-up to #660 ([discussion](https://github.com/apache/hudi-rs/pull/660#discussion_r3788329728)). ## How are the changes test-covered - [ ] N/A - [x] Automated tests (unit and/or integration tests) - [ ] Manual tests - [ ] Details are described below The fixture joins the existing sweep and passes on both reader versions; the `KNOWN` list is not touched. Checked by mutation, each reverted after: dropping the ordering comparison in the version-2 kernel, applying a stale delete, and dropping the ordering column from the version-1 sort each fail this fixture and nothing else in the corpus. -- 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]
