Matthias, i agree so i've added those two overloads.
Thanks,
Damian
On Thu, 24 Aug 2017 at 21:54 Matthias J. Sax <matth...@confluent.io> wrote:
> Thanks for clarification. I see your point. Java varargs are problematic
> in general IMHO as they force you to put them as last argument making
> parameter ordering unnatural for some cases (as we have it currently in
> the API).
>
> Nevertheless, I think that reading a single topic is the most common
> case and thus I would love to see the overloads as mentioned in my last
> email in addition to the overloads taking a Collection of topics. Maybe
> it's just personal taste -- I agree that the overhead of specifying a
> singleton on not severe, but to me it still feels like a "step backward"
> as reading a single topic should be the pattern for like 90% or more of
> the cases.
>
>
> -Matthias
>
>
> On 8/24/17 12:03 PM, Guozhang Wang wrote:
> > Matthias,
> >
> > I think it's my bad that I did not post another comment on the mailing
> list
> > while syncing with Damian. Here it is:
> >
> > Regarding 1) above, a second thought on varargs: though I have not heard
> > from anyone using multiple topics, it is also true that people will just
> > keep silent until their APIs gets removed. So instead of keeping a single
> > topic name in the constructor, it'd better to still allow users to pass
> > multiple topics, as a Collection<String> topic.
> >
> > It does mean that users who would only want a single topic would feel
> > inconvenient with "Collections.singleton(topic)", but I felt it is not
> too
> > big of an issue. On the other hand KafkaConsumer also only allow
> > `subscribe(Collection<String> topics)` so I'd suggest in this KIP we do
> not
> > have two overloads of "stream(topic)" and "stream(topics)" and consider
> > adding that as a syntax-sugar if it does become a big complaint.
> >
> >
> > Guozhang
> >
> >
> >
> > On Thu, Aug 24, 2017 at 11:32 AM, Matthias J. Sax <matth...@confluent.io
> >
> > wrote:
> >
> >> We now have
> >>
> >>> public synchronized <K, V> KStream<K, V> stream(final
> Collection<String>
> >> topic, final Consumed<K, V> options)
> >>
> >> This would prevent so write code like
> >>
> >> builder.stream("topic", Consumers.with(...));
> >>
> >> I think, we need methods
> >>
> >> StreamsBuilder#stream(String topic);
> >> StreamsBuilder#stream(String topic, Consumed options);
> >>
> >> Or do I miss anything?
> >>
> >>
> >> -Matthias
> >>
> >>
> >> On 8/24/17 1:53 AM, Damian Guy wrote:
> >>> I've updated the kip to reflect Bill's comment and also to make
> >>> StreamBuilder methods have topic as the first param, i.e.,
> >>> StreamBuilder#stream no longer accepts varargs.
> >>>
> >>> On Thu, 24 Aug 2017 at 09:12 Damian Guy <damian....@gmail.com> wrote:
> >>>
> >>>> On Thu, 24 Aug 2017 at 02:49 Guozhang Wang <wangg...@gmail.com>
> wrote:
> >>>>
> >>>>> I have a couple of comments but otherwise it LGTM:
> >>>>>
> >>>>> 1. For these two functions in StreamsBuilder, the topic String is set
> >> as
> >>>>> the second parameter in between of two options. Would that be better
> >> to be
> >>>>> set as the first or the last one instead?
> >>>>>
> >>>>> It would be better as the first, but then it is different to the
> >>>> #streams() methods due to varargs.
> >>>>
> >>>>
> >>>>> public synchronized <K, V> KTable<K, V> table(final Consumed<K, V>
> >>>>> consumed, final String topic, final Materialized<K, V> materialized)
> >>>>>
> >>>>> public synchronized <K, V> GlobalKTable<K, V> globalTable(final
> >>>>> Consumed<K,
> >>>>> V> consumed, final String topic, final Materialized<K, V>
> materialized)
> >>>>>
> >>>>> I understand that we cannot do it for the first parameter because of
> >> the
> >>>>> vararg type. So I'd suggest either
> >>>>>
> >>>>> a) set it as the last parameter, but then it is inconsistent with
> other
> >>>>> functions like these:
> >>>>>
> >>>>> void to(final String topic, final Produced<V, V> options);
> >>>>>
> >>>>> KTable<K, V> through(final String topic, final Materialized<K, V>
> >>>>> options);
> >>>>>
> >>>>> b) only allow one single topic name parameter in
> >> StreamsBuilder.stream()
> >>>>> since in practice we do not see too many usages of multiple topics,
> >> plus
> >>>>> it
> >>>>> can be semi-supported with "merge" as we move it from StreamsBuilder
> to
> >>>>> KStream (KAFKA-5765),
> >>>>>
> >>>>> Perhaps this is the better approach
> >>>>
> >>>>
> >>>>> 2. KGroupedStream's function:
> >>>>>
> >>>>> <VR> KTable<K, VR> aggregate(final Initializer<VR> initializer,
> >>>>> final Aggregator<? super K, ? super V,
> VR>
> >>>>> aggregator,
> >>>>> final Serde<VR> aggValueSerde,
> >>>>> final Materialized<K, VR,
> KeyValueStore<K,
> >>>>> VR>> materialized);
> >>>>>
> >>>>> The "aggValueSerde" seems not needed?
> >>>>>
> >>>>> 3. +1 on `KGroupedStream` v.s. `GroupedKStream`. I think
> KGroupedStream
> >>>>> was
> >>>>> a bad name as a hind-sight. I personally feel we should just correct
> it
> >>>>> with a new class and deprecate / remove the old one before 1.0.0, but
> >> that
> >>>>> could be in its own KIP.
> >>>>>
> >>>>>
> >>>> The problem with this is that we'd need to add new `groupBy` and
> >>>> `groupByKey` methods that return `GroupedKStream`, we can't change the
> >>>> existing ones as that would break compatibility. So what would we name
> >>>> these methods?
> >>>>
> >>>>
> >>>>>
> >>>>> Guozhang
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Wed, Aug 23, 2017 at 1:01 PM, Damian Guy <damian....@gmail.com>
> >> wrote:
> >>>>>
> >>>>>> We already have GlobalKTable and i can't rename KGroupedStream,
> which
> >>>>>> really should be GroupedKStream. So I think we should name new
> things
> >>>>>> correctly, i.e., WindowedKStream etc and fix the others when we can.
> >>>>>>
> >>>>>> On Wed, 23 Aug 2017 at 20:38 Matthias J. Sax <matth...@confluent.io
> >
> >>>>>> wrote:
> >>>>>>
> >>>>>>> About KGroupedStream vs GroupedKStream: shouldn't we keep the
> naming
> >>>>>>> convention consistent? And if we change the naming schema just
> change
> >>>>>>> all at once? I personally don't care which naming scheme is better,
> >>>>> but
> >>>>>>> I think consistency is super important!
> >>>>>>>
> >>>>>>> About Bill's comment: I agree, and had a similar thought.
> >>>>>>>
> >>>>>>>
> >>>>>>> -Matthias
> >>>>>>>
> >>>>>>> On 8/23/17 12:24 PM, Bill Bejeck wrote:
> >>>>>>>> Thanks for all the work on this KIP Damian.
> >>>>>>>>
> >>>>>>>> Both `Produced` and `Joined` have a `with` method accepting all
> >>>>>>> parameters,
> >>>>>>>> but `Consumed` doesn't. Should we add one for consistency?
> >>>>>>>>
> >>>>>>>> Thanks,
> >>>>>>>> Bill
> >>>>>>>>
> >>>>>>>> On Wed, Aug 23, 2017 at 4:15 AM, Damian Guy <damian....@gmail.com
> >
> >>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> KIP has been updated. thanks
> >>>>>>>>>
> >>>>>>>>> On Wed, 23 Aug 2017 at 09:10 Damian Guy <damian....@gmail.com>
> >>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>> Hi Matthias,
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>> KStream:
> >>>>>>>>>>> leftJoin and outerJoin for KStream/KTable join should not have
> >>>>>>>>>>> `JoinWindows` parameter
> >>>>>>>>>>>
> >>>>>>>>>>> Thanks!
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> Nit: TopologyBuilder -> Topology
> >>>>>>>>>>>
> >>>>>>>>>>> Ack
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>> Nit: new class Serialized list static method #with twice
> >>>>>>>>>>>
> >>>>>>>>>>> Ack
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>> WindowedKStream -> for consistency we should either have
> >>>>>>> GroupedKStream
> >>>>>>>>>>> or KWindowedStream... (similar argument for
> >>>>> SessionWindowedKStream)
> >>>>>>>>>>>
> >>>>>>>>>>> We can't rename KGroupedStream -> GroupedKStream without
> breaking
> >>>>>>>>>> compatibility. So we are stuck with it for now. Hopefully in the
> >>>>>> future
> >>>>>>>>> we
> >>>>>>>>>> can rename KGroupedStream to GroupedKStream.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> KGroupedStream
> >>>>>>>>>>> -> why do we use a different name for `sessionWindowedBy()` --
> >>>>> seems
> >>>>>>> to
> >>>>>>>>>>> be cleaner to call both methods `windowedBy()`
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>> I beg to differ that it is cleaner either way!
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> StreamsBuilder#stream -> parameter order is confusing... We
> >>>>> should
> >>>>>>> have
> >>>>>>>>>>> Pattern as second parameter to align both methods.
> >>>>>>>>>>>
> >>>>>>>>>>> Ack
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>> StreamsBuilder#table/globalTable -> move parameter `Consumed`
> as
> >>>>>> first
> >>>>>>>>>>> parameter to align with `#stream`
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> Ack
> >>>>>>>>>>
> >>>>>>>>>>> Produced#with(Serde, Serde)
> >>>>>>>>>>> Produced#with(StreamPartitioner, Serde, Serde)
> >>>>>>>>>>> -> should StreamPartitioner be the third argument instead of
> the
> >>>>>>> first?
> >>>>>>>>>>>
> >>>>>>>>>>> Sure
> >>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> Consumed:
> >>>>>>>>>>> Why do we need 3 different names for the 3 static methods? I
> >>>>> would
> >>>>>> all
> >>>>>>>>>>> of them just call `with()`. Current names sound clumsy to me.
> >>>>> And a
> >>>>>>>>>>> plain `with()` also aligns with the naming of static methods of
> >>>>>> other
> >>>>>>>>>>> classes.
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> I disagree that the names sound clumsy! But yes they should be
> >>>>>> aligned
> >>>>>>>>>> with the others.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> I guess we are also deprecation a bunch of method for
> >>>>>>>>>>> KStream/KTable/KGroupedStream/KGroupedTable and should mention
> >>>>>> which
> >>>>>>>>>>> one? There is just one sentence "Deprecate the existing
> >>>>> overloads.",
> >>>>>>> but
> >>>>>>>>>>> we don't deprecate all existing once. I personally don't care
> to
> >>>>>> much
> >>>>>>> if
> >>>>>>>>>>> we spell deprecated method out explicitly, but right now it's
> not
> >>>>>>>>>>> consistent as we only list methods we add.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>> Should we deprecate `StateStoreSupplier`?
> >>>>>>>>>>>
> >>>>>>>>>> Yep
> >>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> -Matthias
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> On 8/22/17 6:55 AM, Damian Guy wrote:
> >>>>>>>>>>>> I've just updated the KIP with some additional changes
> targeted
> >>>>> at
> >>>>>>>>>>>> StreamsBuilder
> >>>>>>>>>>>>
> >>>>>>>>>>>> Thanks,
> >>>>>>>>>>>> Damian
> >>>>>>>>>>>>
> >>>>>>>>>>>> On Thu, 10 Aug 2017 at 12:59 Damian Guy <damian....@gmail.com
> >
> >>>>>>> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> Got it, thanks.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Does it still make sense to have one static constructors for
> >>>>> each
> >>>>>>>>>>> spec,
> >>>>>>>>>>>>>> with one constructor having only one parameter to make it
> more
> >>>>>>>>> usable,
> >>>>>>>>>>>>>> i.e.
> >>>>>>>>>>>>>> as a user I do not need to give all parameters if I only
> want
> >>>>> to
> >>>>>>>>>>> override
> >>>>>>>>>>>>>> one of them? Maybe we can just name the constructors as
> `with`
> >>>>>> but
> >>>>>>>>>>> I'm not
> >>>>>>>>>>>>>> sure if Java distinguish:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> public static <K, V> Produced<K, V> with(final Serde<K>
> >>>>> keySerde)
> >>>>>>>>>>>>>> public static <K, V> Produced<K, V> with(final Serde<V>
> >>>>>> valueSerde)
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> as two function signatures.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>> No that won't work. That is why we have all options, i.e., on
> >>>>>>> Produce
> >>>>>>>>>>>>> public static <K, V> Produced<K, V> with(final Serde<K>
> >>>>> keySerde,
> >>>>>>>>>>> final Serde<V>
> >>>>>>>>>>>>> valueSerde)
> >>>>>>>>>>>>> public static <K, V> Produced<K, V> with(final
> >>>>>> StreamPartitioner<K,
> >>>>>>>>> V>
> >>>>>>>>>>>>> partitioner, final Serde<K> keySerde, final Serde<V>
> >>>>> valueSerde)
> >>>>>>>>>>>>> public static <K, V> Produced<K, V> keySerde(final Serde<K>
> >>>>>>> keySerde)
> >>>>>>>>>>>>> public static <K, V> Produced<K, V> valueSerde(final Serde<V>
> >>>>>>>>>>> valueSerde)
> >>>>>>>>>>>>> public static <K, V> Produced<K, V> streamPartitioner(final
> >>>>>>>>>>> StreamPartitioner<K,
> >>>>>>>>>>>>> V> partitioner)
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> So if you only want to use one you can just use the function
> >>>>> that
> >>>>>>>>> takes
> >>>>>>>>>>>>> one argument.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Guozhang
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> On Wed, Aug 9, 2017 at 6:20 AM, Damian Guy <
> >>>>> damian....@gmail.com
> >>>>>>>
> >>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On Tue, 8 Aug 2017 at 20:11 Guozhang Wang <
> >>>>> wangg...@gmail.com>
> >>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Damian,
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Thanks for the proposal, I had a few comments on the APIs:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> 1. Printed#withFile seems not needed, as users should
> always
> >>>>>> spec
> >>>>>>>>> if
> >>>>>>>>>>>>>> it
> >>>>>>>>>>>>>>> is
> >>>>>>>>>>>>>>>> to sysOut or to File at the beginning. In addition as a
> >>>>> second
> >>>>>>>>>>>>>> thought, I
> >>>>>>>>>>>>>>>> think serdes are not useful for prints anyways since we
> >>>>> assume
> >>>>>>>>>>>>>> `toString`
> >>>>>>>>>>>>>>>> is provided except for byte arrays, in which we will
> special
> >>>>>>>>> handle
> >>>>>>>>>>>>>> it.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> +1
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Another comment about Printed in general is it differs
> with
> >>>>>> other
> >>>>>>>>>>>>>> options
> >>>>>>>>>>>>>>>> that it is a required option than optional one, since it
> >>>>>> includes
> >>>>>>>>>>>>>>> toSysOut
> >>>>>>>>>>>>>>>> / toFile specs; what are the pros and cons for including
> >>>>> these
> >>>>>>> two
> >>>>>>>>>>> in
> >>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>> option and hence make it a required option than leaving
> >>>>> them at
> >>>>>>>>> the
> >>>>>>>>>>>>>> API
> >>>>>>>>>>>>>>>> layer and make Printed as optional for mapper / label
> only?
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> It isn't required as we will still have the no-arg print()
> >>>>> which
> >>>>>>>>> will
> >>>>>>>>>>>>>> just
> >>>>>>>>>>>>>>> go to sysout as it does now.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> 2.1 KStream#through / to
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> We should have an overloaded function without Produced?
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Yes - we already have those so they are not part of the
> KIP,
> >>>>>> i.e,
> >>>>>>>>>>>>>>> through(topic)
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> 2.2 KStream#groupBy / groupByKey
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> We should have an overloaded function without Serialized?
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Yes, as above
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> 2.3 KGroupedStream#count / reduce / aggregate
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> We should have an overloaded function without
> Materialized?
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> As above
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> 2.4 KStream#join
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> We should have an overloaded function without Joined?
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> as above
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> 2.5 Each of KTable's operators:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> We should have an overloaded function without Produced /
> >>>>>>>>> Serialized
> >>>>>>>>>>> /
> >>>>>>>>>>>>>>>> Materialized?
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> as above
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> 3.1 Produced: the static functions have overlaps, which
> >>>>> seems
> >>>>>> not
> >>>>>>>>>>>>>>>> necessary. I'd suggest jut having the following three
> static
> >>>>>> with
> >>>>>>>>>>>>>> another
> >>>>>>>>>>>>>>>> three similar member functions:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> public static <K, V> Produced<K, V> withKeySerde(final
> >>>>> Serde<K>
> >>>>>>>>>>>>>> keySerde)
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> public static <K, V> Produced<K, V> withValueSerde(final
> >>>>>> Serde<V>
> >>>>>>>>>>>>>>>> valueSerde)
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> public static <K, V> Produced<K, V>
> >>>>> withStreamPartitioner(final
> >>>>>>>>>>>>>>>> StreamPartitioner<K, V> partitioner)
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> The key idea is that by using the same function name
> string
> >>>>> for
> >>>>>>>>>>> static
> >>>>>>>>>>>>>>>> constructor and member functions, users do not need to
> >>>>> remember
> >>>>>>>>> what
> >>>>>>>>>>>>>> are
> >>>>>>>>>>>>>>>> the differences but can call these functions with any
> >>>>> ordering
> >>>>>>>>> they
> >>>>>>>>>>>>>> want,
> >>>>>>>>>>>>>>>> and later calls on the same spec will win over early
> calls.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> That would be great if java supported it, but it doesn't.
> You
> >>>>>>> can't
> >>>>>>>>>>> have
> >>>>>>>>>>>>>>> static an member functions with the same signature.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> 3.2 Serialized: similarly
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> public static <K, V> Serialized<K, V> withKeySerde(final
> >>>>>> Serde<K>
> >>>>>>>>>>>>>>> keySerde)
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> public static <K, V> Serialized<K, V> withValueSerde(final
> >>>>>>>>> Serde<V>
> >>>>>>>>>>>>>>>> valueSerde)
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> public Serialized<K, V> withKeySerde(final Serde<K>
> >>>>> keySerde)
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> public Serialized<K, V> withValueSerde(final Serde
> >>>>> valueSerde)
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> as above
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Also it has a final Serde<V> otherValueSerde in one of its
> >>>>>> static
> >>>>>>>>>>>>>>>> constructor, it that intentional?
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Nope: thanks.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> 3.3. Joined: similarly, keep the static constructor
> >>>>> signatures
> >>>>>>> the
> >>>>>>>>>>>>>> same
> >>>>>>>>>>>>>>> as
> >>>>>>>>>>>>>>>> its corresponding member fields.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> As above
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> 3.4 Materialized: it is a bit special, and I think we can
> >>>>> keep
> >>>>>>> its
> >>>>>>>>>>>>>> static
> >>>>>>>>>>>>>>>> constructors with only two `as` as they are today.K
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> 4. Is there any modifications on StateStoreSupplier? Is it
> >>>>>>> replaced
> >>>>>>>>>>> by
> >>>>>>>>>>>>>>>> BytesStoreSupplier? Seems some more descriptions are
> lacking
> >>>>>>> here.
> >>>>>>>>>>>>>> Also
> >>>>>>>>>>>>>>> in
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> No modifications to StateStoreSupplier. It is superseceded
> by
> >>>>>>>>>>>>>>> BytesStoreSupplier.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> public static <K, V, S extends StateStore> Materialized<K,
> >>>>> V,
> >>>>>> S>
> >>>>>>>>>>>>>>>> as(final StateStoreSupplier<S>
> >>>>>>>>>>>>>>>> supplier)
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Is the parameter in type of BytesStoreSupplier?
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Yep - thanks
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Guozhang
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On Thu, Jul 27, 2017 at 5:26 AM, Damian Guy <
> >>>>>>> damian....@gmail.com
> >>>>>>>>>>
> >>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Updated link:
> >>>>>>>>>>>>>>>>> https://cwiki.apache.org/confluence/display/KAFKA/KIP-
> >>>>>>>>>>>>>>>>> 182%3A+Reduce+Streams+DSL+overloads+and+allow+easier+
> >>>>>>>>>>>>>>>>> use+of+custom+storage+engines
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Thanks,
> >>>>>>>>>>>>>>>>> Damian
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> On Thu, 27 Jul 2017 at 13:09 Damian Guy <
> >>>>> damian....@gmail.com
> >>>>>>>
> >>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Hi,
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> I've put together a KIP to make some changes to the
> >>>>>>> KafkaStreams
> >>>>>>>>>>>>>> DSL
> >>>>>>>>>>>>>>>> that
> >>>>>>>>>>>>>>>>>> will hopefully allow us to:
> >>>>>>>>>>>>>>>>>> 1) reduce the explosion of overloads
> >>>>>>>>>>>>>>>>>> 2) add new features without having to continue adding
> more
> >>>>>>>>>>>>>> overloads
> >>>>>>>>>>>>>>>>>> 3) provide simpler ways for people to use custom storage
> >>>>>>> engines
> >>>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>> wrap
> >>>>>>>>>>>>>>>>>> them with logging, caching etc if desired
> >>>>>>>>>>>>>>>>>> 4) enable per-operator caching rather than global
> caching
> >>>>>>>>> without
> >>>>>>>>>>>>>>>> having
> >>>>>>>>>>>>>>>>>> to resort to supplying a StateStoreSupplier when you
> just
> >>>>>> want
> >>>>>>>>> to
> >>>>>>>>>>>>>>> turn
> >>>>>>>>>>>>>>>>>> caching off.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> The KIP is here:
> >>>>>>>>>>>>>>>>>> https://cwiki.apache.org/confluence/pages/viewpage.
> >>>>>>>>>>>>>>>>> action?pageId=73631309
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Thanks,
> >>>>>>>>>>>>>>>>>> Damian
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>> -- Guozhang
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> --
> >>>>>>>>>>>>>> -- Guozhang
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> -- Guozhang
> >>>>>
> >>>>
> >>>
> >>
> >>
> >
> >
>
>
