Thanks Matthias. Good points! I updated the KIP accordingly.
Bests Alieh On Mon, Feb 23, 2026 at 11:15 AM Lucas Brutschy via dev < [email protected]> wrote: > Thanks for the updates Alieh! > > On Sun, Feb 22, 2026 at 8:52 PM Matthias J. Sax <[email protected]> wrote: > > > > Thanks Alieh. > > > > I like Lucas' idea about "format" vs "type". > > > > > > For the downgrade path, KIP-1271 says: > > > > > Downgrades are not supported; the only way to achieve one is by > deleting the local store and rebuilding it from the changelog. > > > > While KIP-1285 only say: > > > > > The same as in KIP-1271, downgrades are not supported. > > > > Might be good to align both? > > > > > > > > One last question: Should we call out that > > `Materialized.as(KeyValueBytesStoreSupplier)` (same for window and > > session case), will also allow to enable a headers store on a per-store > > basis, similar to the plain-kv / ts-case? Ie, if one uses > > > > > Materialized.as( > > > Stores.persistentTimestampedKeyValueStoreWithHeaders(...) > > > ) > > > > The corresponding DSL operator would also use a header store, > > overwriting whatever is configured via `StreamsConfig`. > > > > > > While it's unfortunately not well documented, it is currently possible > > to pass in both types of supplier, and the DSL would "bridge" between > > both store types. Thus, it's currently possible, to disable ts-stores in > > the DSL via > > > > > Materialized.as( > > > Stores.persistentKeyValueStore(...) > > > ) > > > > The determining factor is, if the passed-in supplier implements > > `TimestampedBytesStore` or not and we added a similar marker interface > > `HeaderBytesStore` with KIP-1271, to we can do the same thing for header > > stores. > > > > This should not imply any more code changes I believe, but should work > > this way automatically base on KIP-1285 proposal. I think it's mainly an > > documentation question. > > > > > > > > -Matthias > > > > > > > > > > On 2/22/26 6:16 AM, Alieh Saeedi via dev wrote: > > > Thanks Lucas for the feedback. > > > > > > LB1) dsl.store.type makes sense to me, but I’m not attached to it. I > can > > > change it (and already have changed it) to dsl.store.format if we > prefer > > > that naming. > > > > > > LB2) Since Kafka Streams does not have a timestamped session store, we > > > don’t have any DslSessionParams constructor with isTimestamped. What > we > > > are deprecating in the KIP is the older constructor that does not take > a > > > DslStoreType (now DslStoreFormat). To keep things cleaner, we only > keep a > > > single constructor that also includes DslStoreFormat. For session > stores, > > > DEFAULT corresponds to the regular session store, and HEADERS > corresponds > > > to SessionStoreWithHeaders. This detail is already mentioned in the > KIP. > > > > > > LB3) Because this KIP does not introduce any new state store formats, > the > > > upgrade and downgrade paths are identical to those described in > KIP-1271. > > > I’ve added this note to the KIP as well. > > > > > > Thanks, > > > Alieh > > > > > > On Fri, Feb 20, 2026 at 9:08 PM Lucas Brutschy <[email protected] > > > > > wrote: > > > > > >> Hi Alieh, > > >> > > >> Thanks for the KIP. A few thoughts below. > > >> > > >> LB1: The config name dsl.store.type feels a bit ambiguous since we > > >> already have dsl.store.suppliers.class (which controls RocksDB vs. > > >> in-memory). dsl.store.type could be confused with that distinction. > > >> Would something like dsl.store.format be clearer, since this is really > > >> about the value format (timestamped vs. timestamped+headers)? > > >> > > >> LB2: Regarding DslSessionParams: the current code entirely lacks an > > >> isTimestamped field or constructor parameter. The KIP shows > > >> deprecating a constructor with isTimestamped on DslSessionParams, but > > >> that constructor does not exist today. Could you clarify whether the > > >> KIP intends to add and immediately deprecate the constructor, or > > >> whether the old DslSessionParams constructor should simply remain > > >> as-is and a new overload with DslStoreType should be added alongside > > >> it? > > >> > > >> LB3: Regarding compatibility, the KIP mentions that switching from > > >> DEFAULT to HEADERS triggers KIP-1271 upgrade paths. It would be good > > >> to clarify whether switching back from HEADERS to DEFAULT is also > > >> supported (i.e., is it a two-way migration or one-way only?). If it is > > >> one-way, that must be documented explicitly. > > >> > > >> Thanks, > > >> Lucas > > >> > > >> On Fri, Feb 20, 2026 at 10:30 AM Alieh Saeedi via dev > > >> <[email protected]> wrote: > > >>> > > >>> Hey Matthias, > > >>> Thanks for the suggestions. I agree with all of them. They all make > sense > > >>> to me. I updated the KIP accordingly. > > >>> > > >>> Bests, > > >>> Alieh > > >>> > > >>> On Thu, Feb 19, 2026 at 8:33 PM Matthias J. Sax <[email protected]> > > >> wrote: > > >>> > > >>>> Thanks for the KIP. Great follow up to KIP-1271. > > >>>> > > >>>> > > >>>> > > >>>> Nit: The `DSL_STORE_TYPE_DOC` should be `private` and I also think > we > > >>>> can improve the wording -- but that's more of am impl detail, not > > >> really > > >>>> critical for the KIP itself. > > >>>> > > >>>> How about: > > >>>> > > >>>> "Controls the state store type used by the DSL store supplier (see > > >>>> config 'dsl.store.suppliers.class'). 'default' uses timestamped > stores. > > >>>> 'headers' uses the headers-aware stores." > > >>>> > > >>>> > > >>>> > > >>>> MJS1: Should we deprecate the existing `DslKeyValueParams(final > String > > >>>> name, final boolean isTimestamped)` constructor, and make the newly > > >>>> introduced "type" a mandatory parameter? (Cf MJS2 below) > > >>>> > > >>>> > > >>>> > > >>>> MJS2: Should we add new enum `DslStoreType` with DEFAULT and HEADERS > > >>>> value, and change the constructor > > >>>> > > >>>> from > > >>>> - DslKeyValueParams(final String name, final boolean > isTimestamped, > > >>>> final boolean isHeadersEnabled) > > >>>> > > >>>> to > > >>>> - DslKeyValueParams(final String name, final DslStoreType > storeType) > > >>>> > > >>>> This would more align to the newly added String config (and the KIP > > >>>> calls out that we did not want to add a boolean config, what makes > > >> sense > > >>>> to me), and would subsume the existing `isTimestamped` parameter on > the > > >>>> existing constructor which we could remove (Cf MJS1) > > >>>> > > >>>> [We have a similar thing for `group.protocol` config.] > > >>>> > > >>>> > > >>>> If yes, wondering if we should also deprecate `isTimestamped()` and > not > > >>>> add `headersEnabled()` but instead add `storeType()` getter? > > >>>> > > >>>> Similar for window/session Dsl*Parameter classes. > > >>>> > > >>>> > > >>>> > > >>>> -Matthias > > >>>> > > >>>> > > >>>> On 2/18/26 3:30 AM, Alieh Saeedi via dev wrote: > > >>>>> Hi all, > > >>>>> > > >>>>> I’d like to start a discussion on a new KIP, KIP-1285: DSL Opt-in > > >> Support > > >>>>> for Header-Aware State Stores. > > >>>>> > > >>>>> KIP-1271 introduced headers-aware state stores in Kafka Streams. > > >> KIP-1285 > > >>>>> proposes adding corresponding DSL-level opt-in support, so that DSL > > >>>>> applications can take advantage of these headers-aware stores while > > >>>> keeping > > >>>>> existing applications and topologies unchanged by default. > > >>>>> > > >>>>> You can find the KIP here: > > >>>>> > > >>>>> > > >>>> > > >> > https://cwiki.apache.org/confluence/display/KAFKA/KIP-1285%3A+DSL+Opt-in+Support+for+Header-Aware+State+Stores > > >>>>> > > >>>>> Feedback would be greatly appreciated. > > >>>>> > > >>>>> Best, > > >>>>> Alieh > > >>>>> > > >>>> > > >>>> > > >> > > > > > >
