Hey Almog, first off, thanks for the KIP! I (and others) raised concerns over how restrictive the default.dsl.store config would be if not extendable to custom store types, especially given that this seems to be the primary userbase of such a feature. At the time we didn't really have any better ideas for a clean way to achieve that, but what you proposed makes a lot of sense to me. Happy to see a good solution to this, and hopefully others will share my satisfaction :P
I did have one quick piece of feedback which arose from an unrelated question posed to the dev mailing list w/ subject line "ReadOnlyKeyValueStore#range() Semantics" <https://lists.apache.org/thread/jbckmth8d3mcgg0rd670cpvsgwzqlwrm>. I recommend checking out the full thread for context, but it made me think about how we can leverage the new StoreTypeSpec concept as an answer to the long-standing question in Streams: where can we put guarantees of the public contract for RocksDB (or other store implementations) when all the RocksDB stuff is technically internal. Basically, I'm suggesting two things: first, call out in some way (perhaps the StoreTypeSpec javadocs) that each StoreTypeSpec is considered a public contract in itself and should outline any semantic guarantees it does, or does not, make. Second, we should add a note on ordering guarantees in the two OOTB specs: for RocksDB we assert that range queries will honor serialized byte ordering, whereas the InMemory flavor gives no ordering guarantee whatsoever at this time. Thoughts? -Sophie On Thu, Jul 20, 2023 at 4:28 PM Almog Gavra <almog.ga...@gmail.com> wrote: > Hi All, > > I would like to propose a KIP to expand support for default store types > (KIP-591) to encompass custom store implementations: > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-954%3A+expand+default+DSL+store+configuration+to+custom+types > > Looking forward to your feedback! > > Cheers, > Almog >
