[
https://issues.apache.org/jira/browse/KAFKA-4750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16095052#comment-16095052
]
Guozhang Wang commented on KAFKA-4750:
--------------------------------------
I think technically I'm convinced that option (1) should be a better approach,
the only reason that I'm a bit hesitant in that is as [~mihbor] and [~evis]
discussed previously on this ticket that, for example:
{code}
An example use case would be if the value types are collections. In order to
avoid dealing with nulls in the application layer, one might want to
deserialize null into an empty collection and vice-versa. Would that be a valid
use-case? I can't see why not, but I may be wrong.
{code}
Or more generally are there any common and valid use cases where users do want
to de-serde a not-null object into null bytes, or vice versa. Thinking about it
a bit more, maybe enforcing {{null objects <---> null bytes (meaning
deletion)}} is not too bad since for such use cases above users can still use
some other non-null sentinel byte values.
> 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)
