Hey,
at the moment there is no official API for that -- however, using
`KSTreamBuilder#table()` we internally do the exact some thing -- we
don't create an additional changelog topic, but use the original input
topic for that.
Thus, it might make sense to expose this as official API at Processor
Definitely! Thanks, I'll try this.
On Wed, May 17, 2017 at 10:59 AM, Damian Guy wrote:
> Sorry misread your question!
> If the local state is destroyed there will be no checkpoint file and the
> input topic will be read from the earliest offset. So it will restore all
> state.
>
> On Wed, 17 May
Sorry misread your question!
If the local state is destroyed there will be no checkpoint file and the
input topic will be read from the earliest offset. So it will restore all
state.
On Wed, 17 May 2017 at 09:57 Damian Guy wrote:
> Hi Frank,
>
> Stores.create("store")
> .withKeys(Serdes.
Hi Frank,
Stores.create("store")
.withKeys(Serdes.String())
.withValues(Serdes.String())
.persistent()
.disableLogging()
.build();
Does that help?
Thanks,
Damian
On Wed, 17 May 2017 at 06:09 Frank Lyaruu wrote:
> Hi Kafka people,
>
> I'm using the lo
Hi Kafka people,
I'm using the low level API that often creates a simple state store based
on a (single partition, compacted) topic (It feeds all messages and simply
stores all those messages as-is). Now all these stores get their own
'changelog' topic, to back the state store.
This is fine, but
