Hi Mikael, If you perform an aggregate and thus create another KTable, that KTable will have a changelog topic (and a state store that you can query with Interactive Queris - but this is tangential). It is true that source KTables don't need to create another topic, since they already have one.
I'm not 100% sure if I understood your question correctly. Are you observing something that does not match your expectations? Thanks Eno > On 22 Nov 2016, at 09:59, Mikael Högqvist <hoegqv...@gmail.com> wrote: > > Hi, > > in the documentation for KTable#through, it is stated that a new changelog > topic will be created for the table. It also states that calling through is > equivalent to calling #to followed by KStreamBuilder#table. > > http://kafka.apache.org/0101/javadoc/org/apache/kafka/streams/kstream/KTable.html#through(org.apache.kafka.common.serialization.Serde,%20org.apache.kafka.common.serialization.Serde,%20java.lang.String,%20java.lang.String) > > In the docs for KStreamBuilder#table it is stated that no new changelog > topic will be created since the underlying topic acts as the changelog. > I've verified that this is the case. > > Is there another API method to materialize the results of a KTable > including a changelog, i.e. such that kafka streams creates the topic and > uses the naming schema for changelog topics? The use case I have in mind is > aggregate followed by mapValues. > > Best, > Mikael
