[ https://issues.apache.org/jira/browse/KAFKA-12845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17351308#comment-17351308 ]
Matthias J. Sax commented on KAFKA-12845: ----------------------------------------- I think you confuse "input record key" with "join-key". As you correctly mentioned, we apply a key-extractor to get the join-key for stream side records. This join-key must still be non-null. K10277 only allows that the input record key is null now. Of course, if you use the input record key as join-key, the key-extractor would return the key as-is, and thus, if it's null the record would still be dropped. The issue K10277 addresses is, that if you have a null-key input record, but you key-extractor returns a non-null join-key (from the value of the record), the join should still work. However, before K10277 all records with null-key were dropped, even if the key was not used in the join. Does this make sense? > Rollback change which requires join key to be non null on > KStream->GlobalKTable > ------------------------------------------------------------------------------- > > Key: KAFKA-12845 > URL: https://issues.apache.org/jira/browse/KAFKA-12845 > Project: Kafka > Issue Type: Improvement > Components: streams > Affects Versions: 2.7.0 > Reporter: Pedro Gontijo > Priority: Major > > As part of [KAFKA-10277|https://issues.apache.org/jira/browse/KAFKA-10277] > the behavior for KStream->GlobalKtable joins was changed to require non null > join keys. > But it seems reasonable that not every record will have an existing > relationship (and hence a key) with the join globalktable. Think about a > User>Car for instance, or PageView>Product. An empty/zero key could be > returned by the KeyMapper but that will make a totally unnecessary search > into the store. > I do not think that makes sense for any GlobalKtable join (inner or left) but > for left join it sounds even more strange. > -- This message was sent by Atlassian Jira (v8.3.4#803005)