Very cool.

> On Jul 16, 2016, at 9:55 AM, Damian Guy <damian....@gmail.com> wrote:
> 
> Hi,
> The vote is now complete and KIP-67 has been accepted and adopted.
> Thanks everyone for the input etc.
> 
> Regards,
> Damian
> 
> On Sat, 16 Jul 2016 at 06:53 Damian Guy <damian....@gmail.com> wrote:
> 
>> Hi,
>> Jay's interpretation is correct.
>> Thanks,
>> Damian
>> 
>> 
>> On Fri, 15 Jul 2016 at 16:10, Jay Kreps <j...@confluent.io> wrote:
>> 
>>> 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
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 

Reply via email to