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

Reply via email to