[ 
https://issues.apache.org/jira/browse/KAFKA-4750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16062770#comment-16062770
 ] 

Michal Borowiecki edited comment on KAFKA-4750 at 6/26/17 8:42 AM:
-------------------------------------------------------------------

Deserialiser.deserialize javadoc says:
     * @param data serialized bytes; may be null; implementations are 
recommended to handle null by +returning a value+ or null rather than throwing 
an exception.

If it's fair for deserializer to return a value when a null byte array is 
provided, by symmetry, the serializer should be able to return null when such 
an object is provided and achieve correct round-tripping.

[~evis] In your example, whether its intuitive or not I guess it depends on 
peoples' intuition. To me it is intuitive, since null on a changelog topic is a 
tombstone marker. If I serialize a value to null then to me it's intuitive that 
it's equivalent to deletion, so should not be found in the following get.

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.


was (Author: mihbor):
Deserialiser.deserialize javadoc says:
     * @param data serialized bytes; may be null; implementations are 
recommended to handle null by +returning a value+ or null rather than throwing 
an exception.

If it's fair for deserializer to return a value when a null byte array is 
provided, by symmetry, the serializer should be able to return null when such 
an object is provided and achieve correct round-tripping.

[~evis] In your example, whether its intuitive or not I guess it depends on 
peoples' intuition. To me it is intuitive, since null on a changelog topic is a 
tombstone marker. If I serialize a value to null then it's intuitive that it's 
equivalent to deletion.

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.

> 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.11.0.0, 0.10.2.1
>            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)

Reply via email to