You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@kafka.apache.org by "ASF GitHub Bot (JIRA)" <ji...@apache.org> on 2015/09/28 20:45:04 UTC

[jira] [Commented] (KAFKA-2593) KeyValueStores should not require use of the context's default serializers and deserializers

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

ASF GitHub Bot commented on KAFKA-2593:
---------------------------------------

GitHub user rhauch opened a pull request:

    https://github.com/apache/kafka/pull/255

    KAFKA-2593 Key value stores can use specified serializers and deserializers

    Add support for the key value stores to use specified serializers and deserializers (aka, "serdes"). Prior to this change, the stores were limited to only the default serdes specified in the topology's configuration and exposed to the processors via the ProcessorContext.
    
    Now, using InMemoryKeyValueStore and RocksDBKeyValueStore are similar: both are parameterized on the key and value types, and both have similar multiple static factory methods. The static factory methods either take explicit key and value serdes, take key and value class types so the serdes can be inferred (only for the built-in serdes for string, integer, long, and byte array types), or use the default serdes on the ProcessorContext.

You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/rhauch/kafka kafka-2593

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/kafka/pull/255.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #255
    
----
commit 4e3c1a883ff7470ced79ed747a4fe4893630c220
Author: Randall Hauch <rh...@gmail.com>
Date:   2015-09-28T18:34:51Z

    KAFKA-2593 Key value stores can use custom serializers and deserializers
    
    Add support for the key value stores to use specified serializers and deserializers (aka, "serdes"). Prior to this change, the stores were limited to only the default serdes specified in the topology's configuration and exposed to the processors via the ProcessorContext.
    
    Now, using InMemoryKeyValueStore and RocksDBKeyValueStore are similar: both are parameterized on the key and value types, and both have similar multiple static factory methods. The static factory methods either take explicit key and value serdes, take key and value class types so the serdes can be inferred (only for the built-in serdes for string, integer, long, and byte array types), or use the default serdes on the ProcessorContext.

----


> KeyValueStores should not require use of the context's default serializers and deserializers
> --------------------------------------------------------------------------------------------
>
>                 Key: KAFKA-2593
>                 URL: https://issues.apache.org/jira/browse/KAFKA-2593
>             Project: Kafka
>          Issue Type: Sub-task
>          Components: kafka streams
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>             Fix For: 0.9.0.0
>
>
> Currently the {{InMemoryKeyValueStore}} is only able to use the key and value serializers and deserializers (aka, "serdes") from the {{ProcessingContext}}. This means that a {{Processor}} implementation that wants to use the {{InMemoryKeyValueStore}} can only do this if the key and value types match those set up as the default serdes in the topology's configuration.
> Additionally, the {{RocksDBKeyValueStore}} is only capable of {{byte[]}} keys and values.
> Both of these key-value stores should allow the component using them to specify the serdes for both the keys and values. As a convenience, the current behavior should still be supported, as should a way to infer the serdes for the "built-in" serializers and deserializers (e.g., strings, integers, longs, and byte arrays).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)