My interpretation was that you need an implementation of QueryableStoreType<T> which anyone can do and QueryableStoreTypes is just a place to put the type objects for the types we ship with Kafka.
-Jay On Fri, Jul 15, 2016 at 4:04 PM, Sriram Subramanian <r...@confluent.io> wrote: > 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 <j...@confluent.io> wrote: > > > Cool, I'm +1 after the updates. > > > > -Jay > > > > On Fri, Jul 15, 2016 at 1:50 PM, Damian Guy <damian....@gmail.com> > wrote: > > > > > Hi Guozhang, KIP updated. > > > > > > Thanks, > > > Damian > > > > > > On Fri, 15 Jul 2016 at 13:15 Guozhang Wang <wangg...@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....@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 <ism...@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....@gmail.com > > > > > > > > wrote: > > > > > > > > > > > > > Yes, you get compile time errors > > > > > > > > > > > > > > On Wed, 13 Jul 2016 at 16:22 Damian Guy <damian....@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 <j...@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 > > > > > > > > > >
