You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jira@kafka.apache.org by "Matthias J. Sax (Jira)" <ji...@apache.org> on 2021/06/02 06:51:00 UTC
[jira] [Commented] (KAFKA-12845) Rollback change which requires
join key to be non null on KStream->GlobalKTable
[ https://issues.apache.org/jira/browse/KAFKA-12845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17355514#comment-17355514 ]
Matthias J. Sax commented on KAFKA-12845:
-----------------------------------------
{quote}It was already there. KStream->KTable *and* KStream->GlobalKTable were both ok with null join-keys on left join scenarios.
{quote}
I don't think so. The old condition was:
{code:java}
if (key == null || value == null) {
// drop record
} else {
// compute inner of left join
}
{code}
So for a `null` record-key, the record was dropped for both cases (not that for stream-table joins, record-key and join-key are the same thing). You are right, that we did not have a check in place for the join-key that may be different to the record-key for stream-globalTable join, but back in the days we actually considered it a bug, that was naturally fixed by the change.
{quote} the code change was beyond the proposed when instead of just removing "key == null" from condition "if (*key* == null || value == null)" at line 69, it made it "if (*mappedKey* == null || value == null)".
{quote}
Why was it beyond the proposed change? The proposed change was to not consider the record-key, but the join-key for the `null` check and it seems that is exactly what the change does? Just "removing key==null" check would have been beyond what K10277 proposed.
Feel free to pick-up K12317 for 3.0 release. Should be an easy fix I guess. (It's not a bug-fix though, as the system does behave as designed – if the design is "bad" it's not a bug in the code. If we change the design, we apply an "improvement" :) – even if I understand that you perceive the change as a regression as you "relied" on the bug and thought it was by-design even if it was not).
Closing this as duplicate now.
> 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)