linliu-code opened a new issue, #19978:
URL: https://github.com/apache/hudi/issues/19978
On a table that orders by event time, `MERGE INTO ... WHEN MATCHED THEN
DELETE` does not mean the same thing on Copy on Write and Merge on Read.
On COW the delete is resolved at write time by `ExpressionPayload`, whose
delete branch returns an empty record without ever reading the target record,
so the delete always applies.
On MOR the delete is written into a log delete block carrying the source
row's ordering value, and the reader discards it whenever the stored record's
ordering value is greater. A row the statement asked to delete can therefore
survive, silently.
Reproduction on a MOR table with `preCombineField = 'ts'` and
`hoodie.record.merge.mode = 'EVENT_TIME_ORDERING'`:
```sql
insert into t select 1 as id, 'A' as name, 100L as ts;
merge into t using (select 1 as id, 'B' as name, 99L as ts) s
on t.id = s.id
when matched then delete;
select * from t; -- row 1 is still there on MOR, gone on COW
```
`TestMergeModeEventTimeOrdering` already encodes this asymmetry: its merge
case is fenced behind `if ("mor".equals(tableType))` with a comment noting that
COW does not honor event time ordering for MIT deletes.
Worth noting that `DELETE FROM` ignores ordering values on both table types
and both merge modes (see `TestDeleteFromTable`, which parameterizes over all
four combinations), so MERGE INTO is currently the only SQL delete surface
where a delete can be dropped.
This issue tracks making the two table types agree. Reported previously as
HUDI-8915 / #17372, which framed it as a COW bug; the two table types actually
disagree, and the resolution direction is the other way round.
--
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]
