Re: Fwd: [DISCUSS] KIP-114: KTable materialization and improved semantics

Hi Gwen, this is not a hint as in "make it smarter" this is a hint as to "make it work" wich should not require hinting. Best Jan On 27.01.2017 22:35, Gwen Shapira wrote: Another vote in favor of overloading. I think the streams API actually trains users quite well in realizing the

Re: Fwd: [DISCUSS] KIP-114: KTable materialization and improved semantics

Hi Exactly I know it works from the Processor API, but my suggestion would prevent DSL users dealing with storenames what so ever. In general I am pro switching between DSL and Processor API easily. (In my Stream applications I do this a lot with reflection and instanciating KTableImpl)

Re: Fwd: [DISCUSS] KIP-114: KTable materialization and improved semantics

Another vote in favor of overloading. I think the streams API actually trains users quite well in realizing the implications of adding a state-store - we need to figure out the correct Serde every single time :) Another option: "materialize" behaves almost as a SQL hint - i.e. allows a user to

Re: Fwd: [DISCUSS] KIP-114: KTable materialization and improved semantics

Jan, the IQ feature is not limited to Streams DSL but can also be used for Stores used in PAPI. Thus, we need a mechanism that does work for PAPI and DSL. Nevertheless I see your point and I think we could provide a better API for KTable stores including the discovery of remote shards of the

Re: Fwd: [DISCUSS] KIP-114: KTable materialization and improved semantics

Yeah, Maybe my bad that I refuse to look into IQ as i don't find them anywhere close to being interesting. The Problem IMO is that people need to know the Store name), so we are working on different levels to achieve a single goal. What is your peoples opinion on having a method on KTABLE

Re: Fwd: [DISCUSS] KIP-114: KTable materialization and improved semantics

I think Jan is saying that they don't always need to be materialized, i.e., filter just needs to apply the ValueGetter, it doesn't need yet another physical state store. On Fri, 27 Jan 2017 at 15:49 Michael Noll wrote: > Like Damian, and for the same reasons, I am more in

Re: Fwd: [DISCUSS] KIP-114: KTable materialization and improved semantics

Like Damian, and for the same reasons, I am more in favor of overloading methods rather than introducing `materialize()`. FWIW, we already have a similar API setup for e.g. `KTable#through(topicName, stateStoreName)`. A related but slightly different question is what e.g. Jan Filipiak mentioned

Re: Fwd: [DISCUSS] KIP-114: KTable materialization and improved semantics

Hi, Yeah its confusing, Why shoudn't it be querable by IQ? If you uses the ValueGetter of Filter it will apply the filter and should be completely transparent as to if another processor or IQ is accessing it? How can this new method help? I cannot see the reason for the additional

Fwd: [DISCUSS] KIP-114: KTable materialization and improved semantics

Forwarding this thread to the users list too in case people would like to comment. It is also on the dev list. Thanks Eno > Begin forwarded message: > > From: "Matthias J. Sax" > Subject: Re: [DISCUSS] KIP-114: KTable materialization and improved semantics > Date: 24