To make it clear, it’s outlined by Damian, I just copy pasted what he told me
in person :)
Eno
> On Jun 21, 2017, at 4:40 PM, Bill Bejeck <bbej...@gmail.com> wrote:
>
> +1 for the approach outlined above by Eno.
>
> On Wed, Jun 21, 2017 at 11:28 AM, Damian Guy <damian....@gmail.com> wrote:
>
>> Thanks Eno.
>>
>> Yes i agree. We could apply this same approach to most of the operations
>> where we have multiple overloads, i.e., we have a single method for each
>> operation that takes the required parameters and everything else is
>> specified as you have done above.
>>
>> On Wed, 21 Jun 2017 at 16:24 Eno Thereska <eno.there...@gmail.com> wrote:
>>
>>> (cc’ing user-list too)
>>>
>>> Given that we already have StateStoreSuppliers that are configurable
>> using
>>> the fluent-like API, probably it’s worth discussing the other examples
>> with
>>> joins and serdes first since those have many overloads and are in need of
>>> some TLC.
>>>
>>> So following your example, I guess you’d have something like:
>>> .join()
>>> .withKeySerdes(…)
>>> .withValueSerdes(…)
>>> .withJoinType(“outer”)
>>>
>>> etc?
>>>
>>> I like the approach since it still remains declarative and it’d reduce
>> the
>>> number of overloads by quite a bit.
>>>
>>> Eno
>>>
>>>> On Jun 21, 2017, at 3:37 PM, Damian Guy <damian....@gmail.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>> I'd like to get a discussion going around some of the API choices we've
>>>> made in the DLS. In particular those that relate to stateful operations
>>>> (though this could expand).
>>>> As it stands we lean heavily on overloaded methods in the API, i.e,
>> there
>>>> are 9 overloads for KGroupedStream.count(..)! It is becoming noisy and
>> i
>>>> feel it is only going to get worse as we add more optional params. In
>>>> particular we've had some requests to be able to turn caching off, or
>>>> change log configs, on a per operator basis (note this can be done now
>>> if
>>>> you pass in a StateStoreSupplier, but this can be a bit cumbersome).
>>>>
>>>> So this is a bit of an open question. How can we change the DSL
>> overloads
>>>> so that it flows, is simple to use and understand, and is easily
>> extended
>>>> in the future?
>>>>
>>>> One option would be to use a fluent API approach for providing the
>>> optional
>>>> params, so something like this:
>>>>
>>>> groupedStream.count()
>>>> .withStoreName("name")
>>>> .withCachingEnabled(false)
>>>> .withLoggingEnabled(config)
>>>> .table()
>>>>
>>>>
>>>>
>>>> Another option would be to provide a Builder to the count method, so it
>>>> would look something like this:
>>>> groupedStream.count(new
>>>> CountBuilder("storeName").withCachingEnabled(false).build())
>>>>
>>>> Another option is to say: Hey we don't need this, what are you on
>> about!
>>>>
>>>> The above has focussed on state store related overloads, but the same
>>> ideas
>>>> could be applied to joins etc, where we presently have many join
>> methods
>>>> and many overloads.
>>>>
>>>> Anyway, i look forward to hearing your opinions.
>>>>
>>>> Thanks,
>>>> Damian
>>>
>>>
>>
