Hi Matthias, Thanks for comments.
- why do you only consider get() and not range() and all() ? The corresponding jira concentrates on single key lookups. Moreover, I could not find a use-case to include range queries to return records with timestamp. However, theoritically we can include range() and all() as well. - we cannot have a second get() (this would be ambiguous) but need > another name like getWithTs() (or something better) - what use case do you have in mind for getKeyTs() ? Would a single new > method returning KeyContext not be sufficient? Thanks for correction, this is my bad. - for backward compatibility, we will also need a new interface and > cannot just extend the existing one I will correct the KIP accordingly. Thanks, Jeyhun On Fri, Jun 2, 2017 at 7:36 AM, Matthias J. Sax <matth...@confluent.io> wrote: > Thanks for the KIP Jeyhun. > > Some comments: > - why do you only consider get() and not range() and all() ? > - we cannot have a second get() (this would be ambiguous) but need > another name like getWithTs() (or something better) > - what use case do you have in mind for getKeyTs() ? Would a single new > method returning KeyContext not be sufficient? > - for backward compatibility, we will also need a new interface and > cannot just extend the existing one > > > > -Matthias > > On 5/29/17 4:55 PM, Jeyhun Karimov wrote: > > Dear community, > > > > I want to share KIP-165 [1] based on issue KAFKA-4304 [2]. > > I would like to get your comments. > > > > [1] > > https://cwiki.apache.org/confluence/display/KAFKA/KIP- > 165%3A+Extend+Interactive+Queries+for+return+latest+ > update+timestamp+per+key > > [2] https://issues.apache.org/jira/browse/KAFKA-4304 > > > > Cheers, > > Jeyhun > > > >
