kafka-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matthias J. Sax" <matth...@confluent.io>
Subject Re: [DISCUSS] KIP-165: Extend Interactive Queries for return latest update timestamp per key
Date Wed, 16 Jan 2019 22:45:51 GMT
Hi,

This issue seems to be resolved as part of KIP-258. Thus, I close this
discussion and mark this KIP as discarded.

Let me know if there is any objection. Thanks.


-Matthias


On 12/4/17 4:06 PM, Matthias J. Sax wrote:
> Jeyhun,
> 
> is there any update regarding this KIP?
> 
> 
> -Matthias
> 
> On 10/13/17 10:39 AM, Matthias J. Sax wrote:
>> I wanted to follow up with this KIP.
>>
>> One important thing that is missing in this KIP, is the question where
>> the TS is coming from? ATM, timestamps are not stored in the state
>> stores -- it's a plain <key,value> format.
>>
>> Thus, if we want to enable this feature, we need to change the data
>> format of the stores. This also required an upgrade path for
>> applications to migrate from the old format to the new format.
>>
>>
>> -Matthias
>>
>> On 6/27/17 2:16 PM, Jeyhun Karimov wrote:
>>> Hi Michal,
>>>
>>>
>>> Thanks a lot for your comment. I fixed  the document.
>>>
>>> Cheers,
>>> Jeyhun
>>>
>>> On Sat, Jun 24, 2017 at 6:49 PM Michal Borowiecki
>>> <michal.borowiecki@openbet.com <mailto:michal.borowiecki@openbet.com>>
>>> wrote:
>>>
>>>     Hi Jeyhun,
>>>
>>>     Could the proposed KeyContext.keyTs() be made more descriptive?
>>>
>>>     e.g. lastUpdated() or similar? So that users don't have to read the
>>>     docs to know it isn't the creation timestamp for instance.
>>>
>>>     Cheers,
>>>     Michał
>>>
>>>
>>>     On 04/06/17 01:24, Jeyhun Karimov wrote:
>>>>     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 <matthias@confluent.io>
<mailto:matthias@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
>>>>>>
>>>>>
>>>
>>>     -- 
>>>     <http://www.openbet.com/> 	Michal Borowiecki
>>>     Senior Software Engineer L4
>>>     	T: 	+44 208 742 1600 <tel:+44%2020%208742%201600>
>>>
>>>     	
>>>     	+44 203 249 8448 <tel:+44%2020%203249%208448>
>>>
>>>     	
>>>     	 
>>>     	E: 	michal.borowiecki@openbet.com
>>>     <mailto:michal.borowiecki@openbet.com>
>>>     	W: 	www.openbet.com <http://www.openbet.com/>
>>>
>>>     	
>>>     	OpenBet Ltd
>>>
>>>     	Chiswick Park Building 9
>>>
>>>     	566 Chiswick High Rd
>>>
>>>     	London
>>>
>>>     	W4 5XT
>>>
>>>     	UK
>>>
>>>     	
>>>     <https://www.openbet.com/email_promo>
>>>
>>>     This message is confidential and intended only for the addressee. If
>>>     you have received this message in error, please immediately notify
>>>     the postmaster@openbet.com <mailto:postmaster@openbet.com> and
>>>     delete it from your system as well as any copies. The content of
>>>     e-mails as well as traffic data may be monitored by OpenBet for
>>>     employment and security purposes. To protect the environment please
>>>     do not print this e-mail unless necessary. OpenBet Ltd. Registered
>>>     Office: Chiswick Park Building 9, 566 Chiswick High Road, London, W4
>>>     5XT, United Kingdom. A company registered in England and Wales.
>>>     Registered no. 3134634. VAT no. GB927523612
>>>
>>> -- 
>>> -Cheers
>>>
>>> Jeyhun
>>
> 


Mime
View raw message