[
https://issues.apache.org/jira/browse/KAFKA-14748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17694229#comment-17694229
]
Matthias J. Sax commented on KAFKA-14748:
-----------------------------------------
{quote}Hence, adding a `filter` operator after the `join` operator alone for
`<K, join(V, null)>` cannot preserve the old behavior if a developer really
wants that..
{quote}
Well, user could have a filter before the join, that leverages the
key-extractor and drop the record if the key-extractor returns `null`?
About the question, "do we need to distinguish both cases": I think in the
past, we wanted to distinguish both because we had the "eager emit"
implementation for stream-stream joins, which could lead to "spurious
duplicates" that one might want to filter downstream. Given, the new
implementation of "emit-on-window-close", this issue goes away, and thus, I
don't think we need to be able to distinguish both any longer?
I actually also believe, that "left join because key-extractor returns null"
and "left join because no right hand side value found" is actually the same
anyway?
> Relax non-null FK left-join requirement
> ---------------------------------------
>
> Key: KAFKA-14748
> URL: https://issues.apache.org/jira/browse/KAFKA-14748
> Project: Kafka
> Issue Type: Improvement
> Components: streams
> Reporter: Matthias J. Sax
> Priority: Major
>
> Kafka Streams enforces a strict non-null-key policy in the DSL across all
> key-dependent operations (like aggregations and joins).
> This also applies to FK-joins, in particular to the ForeignKeyExtractor. If
> it returns `null`, it's treated as invalid. For left-joins, it might make
> sense to still accept a `null`, and add the left-hand record with an empty
> right-hand-side to the result.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
