kafka-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sriram Subramanian <...@confluent.io>
Subject Re: [VOTE] KIP-67: Queryable state for Kafka Streams
Date Fri, 15 Jul 2016 23:04:48 GMT
So, it looks like QueryableStoreTypes would be part of the streams library,
right? If a developer needs to support a new store, would they need to
change code in streams?

On Fri, Jul 15, 2016 at 3:15 PM, Jay Kreps <jay@confluent.io> wrote:

> Cool, I'm +1 after the updates.
>
> -Jay
>
> On Fri, Jul 15, 2016 at 1:50 PM, Damian Guy <damian.guy@gmail.com> wrote:
>
> > Hi Guozhang, KIP updated.
> >
> > Thanks,
> > Damian
> >
> > On Fri, 15 Jul 2016 at 13:15 Guozhang Wang <wangguoz@gmail.com> wrote:
> >
> > > Hi Damian,
> > >
> > > Since the StateStoreProvider is moved into internal packages, how about
> > > just keeping the ReadOnlyXXStores interface for the queryAPI, and
> > > "QueryableStoreType" in the discoverAPI, and move the
> StateStoreProvider
> > > / QueryableStoreTypeMatcher and different implementations of the
> matcher
> > > like KeyValueStoreType / etc in a new section called "developer guide
> for
> > > customized stores"? This way we have a separate guidance for Streams
> > users,
> > > from Streams developers.
> > >
> > > Other than that, all LGTM.
> > >
> > > Guozhang
> > >
> > > On Fri, Jul 15, 2016 at 9:57 AM, Damian Guy <damian.guy@gmail.com>
> > wrote:
> > >
> > > > Hi All,
> > > >
> > > > I've updated the KIP with changes as discussed in this Thread.
> > > >
> > > > Thanks,
> > > > Damian
> > > >
> > > > On Wed, 13 Jul 2016 at 16:51 Ismael Juma <ismael@juma.me.uk> wrote:
> > > >
> > > > > I think it's important to distinguish the use cases of defining new
> > > > stores
> > > > > (somewhat rare) versus using the `store` method (very common). The
> > > > strategy
> > > > > employed here is a common way to use generics to ensure type safety
> > for
> > > > the
> > > > > latter case. In the former case, there are all sorts of weird
> things
> > > one
> > > > > could do to defeat the type system, but spending a bit more effort
> to
> > > get
> > > > > it right so that the common case is safer and more pleasant is
> worth
> > > it,
> > > > in
> > > > > my opinion.
> > > > >
> > > > > Ismael
> > > > >
> > > > > On Thu, Jul 14, 2016 at 12:23 AM, Damian Guy <damian.guy@gmail.com
> >
> > > > wrote:
> > > > >
> > > > > > Yes, you get compile time errors
> > > > > >
> > > > > > On Wed, 13 Jul 2016 at 16:22 Damian Guy <damian.guy@gmail.com>
> > > wrote:
> > > > > >
> > > > > > > You wont get a runtime error as you wouldn't find a store
of
> that
> > > > type.
> > > > > > > The API would return null
> > > > > > >
> > > > > > > On Wed, 13 Jul 2016 at 16:22 Jay Kreps <jay@confluent.io>
> wrote:
> > > > > > >
> > > > > > >> But if "my-store" is not of type MyStoreType don't
you still
> > get a
> > > > run
> > > > > > >> time
> > > > > > >> error that in effect is the same as the class cast
would be?
> > > > Basically
> > > > > > the
> > > > > > >> question I'm asking is whether this added complexity
is
> actually
> > > > > moving
> > > > > > >> runtime errors to compile time errors.
> > > > > > >>
> > > > > > >> -Jay
> > > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > -- Guozhang
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message