[
https://issues.apache.org/jira/browse/KAFKA-7918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16767663#comment-16767663
]
Sophie Blee-Goldman commented on KAFKA-7918:
--------------------------------------------
Makes sense, I will consider the caching layer to be outside of the immediate
scope for now. Does it make sense to break up the PR into one for each type of
store (ie kv, window, session)? The implementation changes will be rather minor
but the testing framework requires some overhaul since <Integer, String> is
hardcoded into all the unit tests... (still relatively minor, but certainly
many many lines of code)
> Streams store cleanup: inline byte-store generic parameters
> -----------------------------------------------------------
>
> Key: KAFKA-7918
> URL: https://issues.apache.org/jira/browse/KAFKA-7918
> Project: Kafka
> Issue Type: Improvement
> Components: streams
> Reporter: John Roesler
> Assignee: Sophie Blee-Goldman
> Priority: Major
>
> Currently, the fundamental layer of stores in Streams is the "bytes store".
> The easiest way to identify this is in
> `org.apache.kafka.streams.state.Stores`, all the `StoreBuilder`s require a
> `XXBytesStoreSupplier`.
> We provide several implementations of these bytes stores, typically an
> in-memory one and a persistent one (aka RocksDB).
> Inside these bytes stores, the key is always `Bytes` and the value is always
> `byte[]` (serialization happens at a higher level). However, the store
> implementations are generically typed, just `K` and `V`.
> This is good for flexibility, but it makes the code a little harder to
> understand. I think that we used to do serialization at a lower level, so the
> generics are a hold-over from that.
> It would simplify the code if we just inlined the actual k/v types and maybe
> even renamed the classes from (e.g.) `InMemoryKeyValueStore<K,V>` to
> `InMemoryKeyValueBytesStore`, and so forth.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
