Sophie— Thanks for chiming in here. +1 to the idea of specifying the ordering guarantees that we make in the StorageTypeSpec javadocs.
Quick question then. Is the javadoc that says: > Order is not guaranteed as bytes lexicographical ordering might not represent key order. no longer correct, and should say: > Order guarantees depend on the underlying implementation of the ReadOnlyKeyValueStore. For more information, please consult the [StorageTypeSpec javadocs](....) Thanks, Colt McNealy *Founder, LittleHorse.dev* On Thu, Jul 20, 2023 at 9:28 PM Sophie Blee-Goldman <ableegold...@gmail.com> wrote: > 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 > > >
