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 > >