Page History

...

     KTable table2 = table1.filter(...); // not materialized, i.e.,and not queryable by IQ

• KTables resulting from join() operators are not materialized, because the user does not have the option of materializing them.

...

• Depreciate the following KTable methods: print(), writeAsText(), foreach() and any of their overloads.

Implementation plan

One implementation detail that is important is how the Kafka Streams internals decides whether to materialize a KTable. Note that the above APIs provide a way for Interactive Queries to query a state store. They do not dictate whether the state store itself if a real, materialized one, or a view on top of a real, materialized store. Going back to the first example in the motivation:

KTable table1 = builder.table(..., topic, stateStoreName); // materialized

KTable table2 = table1.filter(final String stateStoreName2)

The store with name "stateStoreName2" could be a view on top of the store with name "stateStoreName", in which case each time we query stateStoreName2, we would, on the fly, compute the result of the filter on values actually stored in the first store. Alternatively, "stateStoreName2" could in itself be materialised, i.e., contain all the results obtained from the filtering. Materialising all Ktables with a state store name could be expensive, however it is a straightforward to implement and could be a good V1. A subsequent JIRA could do an optimization in V2.

Compatibility, Deprecation, and Migration Plan

...