Page History

The main scope of this KIP is to address the inconsistency in which KTables are materialized and what KTables are not. As well as which KTables are queryable and which are not. As such, this KIP should be seen as an incremental update to the existing APIs, not a complete overhaul. 

What is in scope is the exact API for addressing the above consistencyinconsistency.

What is not in scope

• Revisiting the interactive queries APIs is not in scope. Specifically, what is not in scope is re-defining the exact boundary between the DSL (i.e., the processing language) and the storage/interactive queries, and how we jump from one to the other. The boundary will remain as it is today, where to do Interactive Queries, the user needs a store name and receives a store to query based on that name. We can address that in a later KIP if required.

• What is not in scope is rethinking the DSL itself. Specifically, specifying state stores in the API can be thought of as a type of hint to the DSL to indicate that materialization is required. There could be many such hints, and perhaps they could be described with methods such as .materialize(), or .cache(), or .log(). These methods might be getting us towards a less declarative API. Either way, it is not in the scope of this KIP to undertake a complete rethink of the DSL. This KIP stays consistent with the DSL we currently have.