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 implic
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) Conc
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 con
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 same
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 th
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 favor of overloading
>
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 ea
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 materializ
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 January 2017 at 19:30:10 G
