[
https://issues.apache.org/jira/browse/KAFKA-4750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16094568#comment-16094568
]
Matthias J. Sax commented on KAFKA-4750:
----------------------------------------
As mentioned above. I would go with option (1) as null delete semantics also
align with changelog delete semantics. Also, if we would allow to put {{null}}
as regular value, we have the same issue as Java has in general: if a {{get}}
returns {{null}} it's unclear if {{null}} is a regular value or the key is just
not there. Within Java (eg. {{HashMap}}) you still can check with
{{containsKey}} but we don't have an API for this on the stores.
> KeyValueIterator returns null values
> ------------------------------------
>
> Key: KAFKA-4750
> URL: https://issues.apache.org/jira/browse/KAFKA-4750
> Project: Kafka
> Issue Type: Bug
> Components: streams
> Affects Versions: 0.10.1.1, 0.10.2.1, 0.11.0.0
> Reporter: Michal Borowiecki
> Assignee: Evgeny Veretennikov
> Labels: newbie
> Attachments: DeleteTest.java
>
>
> The API for ReadOnlyKeyValueStore.range method promises the returned iterator
> will not return null values. However, after upgrading from 0.10.0.0 to
> 0.10.1.1 we found null values are returned causing NPEs on our side.
> I found this happens after removing entries from the store and I found
> resemblance to SAMZA-94 defect. The problem seems to be as it was there, when
> deleting entries and having a serializer that does not return null when null
> is passed in, the state store doesn't actually delete that key/value pair but
> the iterator will return null value for that key.
> When I modified our serilizer to return null when null is passed in, the
> problem went away. However, I believe this should be fixed in kafka streams,
> perhaps with a similar approach as SAMZA-94.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
