+1 (binding) from me as well. On Wed, Jan 22, 2020 at 5:59 PM Matthias J. Sax <matth...@confluent.io> wrote:
> I have a few minor comments (compare the DISCUSS thread), but overall > the KIP looks good. > > +1 (binding) > > > -Matthias > > On 1/22/20 10:09 AM, John Roesler wrote: > > Thanks for updating the KIP, Navinder. > > > > I'm +1 (binding) on the current proposal > > > > Thanks, > > -John > > > > On Tue, Jan 21, 2020, at 12:50, Navinder Brar wrote: > >> Thanks, Guozhang. I agree it makes total sense. I will make the > >> edits.~Navinder > >> > >> On Tuesday, 21 January, 2020, 11:00:32 pm IST, Guozhang Wang > >> <wangg...@gmail.com> wrote: > >> > >> Hello Navinder, > >> > >> Thanks for brining up this proposal. I made a quick pass on that and > >> overall I think I agree with your ideas. Just a few thoughts about the > >> public APIs: > >> > >> 1) As we are adding a new overload to `KafkaStreams#store`, could we > just > >> add the storeName and queryableStoreType as part of StoreQueryParam, and > >> leaving that the only parameter of the function? > >> > >> 2) along with 1), for the static constructors, instead of iterating over > >> all possible combos I'd suggest we make constructors with only, say, > >> storeName, and then adding `withXXX()` setters to set other fields. > This is > >> in case we want to add more param fields into the object, that we do not > >> need to exponentially adding and deprecating the static constructors. > >> > >> > >> Guozhang > >> > >> > >> On Mon, Jan 20, 2020 at 10:42 AM Navinder Brar > >> <navinder_b...@yahoo.com.invalid> wrote: > >> > >>> Hello all, > >>> > >>> I'd like to propose a vote to serve keys from a specific > partition-store > >>> instead of iterating over all the local stores of an instance to > locate the > >>> key, as which happens currently. > >>> The full KIP is provided here: > >>> > >>> > https://cwiki.apache.org/confluence/display/KAFKA/KIP-562%3A+Allow+fetching+a+key+from+a+single+partition+rather+than+iterating+over+all+the+stores+on+an+instance > >>> > >>> > >>> Thanks, > >>> Navinder > >>> > >> > >> > >> -- > >> -- Guozhang > >> > > -- -- Guozhang
