...
Depreciate the following KTable methods: print(), writeAsText(), foreach() and any of their overloads.
Interfaces / API Changes (PAPI only)
During implementation it became clear that a minor adjustment was needed and org.apache.kafka.streams.processor.addGlobalStore should take a
"final StateStoreSupplier<KeyValueStore>" type as the first argument, not a StateStore. Note that one can obtain a StateStore by calling the .get() method on a StateStoreSupplier.
Misc API cleanup
During implementation it became apparent that some APIs needed minor renaming or cleanup. That is listed here:
- KTable.getStoreName() -> Ktable.queryableStoreName(). Reason is that in Kafka we don't usually use the "get" prefix.
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:
...
- Will depreciate the KTable methods print(), writeAsText(), foreach() and any of their overloads.
Code will be backwards compatible.
- PAPI code that uses org.apache.kafka.streams.processor.addGlobalStore will need to use new API signature.
Rejected Alternatives
Change the name of KTable. We discussed potentially changing the name of a KTable to something like KChangelogStream, but this doesn’t solve the main problem this KIP addresses, which is API inconsistency.
...