I noticed this (lack of primary parameter) as well. What you gave as new example is semantically the same as what I suggested. So it is good by me.
Thanks On Wed, Jun 27, 2018 at 7:31 AM, John Roesler <j...@confluent.io> wrote: > Thanks for taking look, Ted, > > I agree this is a departure from the conventions of Streams DSL. > > Most of our config objects have one or two "required" parameters, which fit > naturally with the static factory method approach. TimeWindow, for example, > requires a size parameter, so we can naturally say TimeWindows.of(size). > > I think in the case of a suppression, there's really no "core" parameter, > and "Suppression.of()" seems sillier than "new Suppression()". I think that > Suppression.of(duration) would be ambiguous, since there are many durations > that we can configure. > > However, thinking about it again, I suppose that I can give each > configuration method a static version, which would let you replace "new > Suppression()." with "Suppression." in all the examples. Basically, instead > of "of()", we'd support any of the methods I listed. > > For example: > > windowCounts > .suppress( > Suppression > .suppressLateEvents(Duration.ofMinutes(10)) > .suppressIntermediateEvents( > IntermediateSuppression.emitAfter(Duration.ofMinutes(10)) > ) > ); > > > Does that seem better? > > Thanks, > -John > > > On Wed, Jun 27, 2018 at 12:44 AM Ted Yu <yuzhih...@gmail.com> wrote: > > > I started to read this KIP which contains a lot of materials. > > > > One suggestion: > > > > .suppress( > > new Suppression() > > > > > > Do you think it would be more consistent with the rest of Streams data > > structures by supporting `of` ? > > > > Suppression.of(Duration.ofMinutes(10)) > > > > > > Cheers > > > > > > > > On Tue, Jun 26, 2018 at 1:11 PM, John Roesler <j...@confluent.io> wrote: > > > > > Hello devs and users, > > > > > > Please take some time to consider this proposal for Kafka Streams: > > > > > > KIP-328: Ability to suppress updates for KTables > > > > > > link: https://cwiki.apache.org/confluence/x/sQU0BQ > > > > > > The basic idea is to provide: > > > * more usable control over update rate (vs the current state store > > caches) > > > * the final-result-for-windowed-computations feature which several > people > > > have requested > > > > > > I look forward to your feedback! > > > > > > Thanks, > > > -John > > > > > >
