[
https://issues.apache.org/jira/browse/FLINK-40858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18124390#comment-18124390
]
Gustavo de Morais commented on FLINK-40858:
-------------------------------------------
Backported to:
- release-2.3:
[098afcc7990|https://github.com/apache/flink/commit/098afcc79908ceb51c0e84d8d967ca64644ff6ee]
- release-2.2:
[3d20ecb1dfb|https://github.com/apache/flink/commit/3d20ecb1dfb9fdcb25a9d8140796fb8d2ceb506c]
> Streaming join should evaluate non-equi conditions on key-only deletes
> ----------------------------------------------------------------------
>
> Key: FLINK-40858
> URL: https://issues.apache.org/jira/browse/FLINK-40858
> Project: Flink
> Issue Type: Sub-task
> Components: Table SQL / API
> Affects Versions: 2.3.0, 2.2.1, 1.20.5, 2.1.3
> Reporter: Gustavo de Morais
> Assignee: Gustavo de Morais
> Priority: Major
>
> When a join input's upsert key contains the join key, the planner allows
> key-only deletes (ChangelogMode#keyOnlyDeletes) into the join. The deletion
> itself is correct, because the join removes the stored record by its unique
> key. But the operator then evaluates the non-equi condition against the
> incoming delete record, whose non-key columns are null. So it may retract the
> wrong matches or none at all, which leaves stale joined rows and wrong null
> padding.
> Example: {{{}L LEFT JOIN R ON L.k = R.k AND R.v > L.v{}}}, where R is an
> upsert source with key-only deletes and the sink supports deletes by key.
>
> {code:java}
> +I L(k=1, v=5)
> +I R(id=1, k=1, v=10) -> +I[L, R]
> -D R(id=1, k=1) -> v is null, condition is false, [L, R] is never
> retracted {code}
>
> Related: FLINK-40841.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
