You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 9 Next »

Status

Current state: Under Discussion

Discussion thread: here

JIRA: KAFKA-15257 

Please keep the discussion on the mailing list rather than commenting on the wiki (wiki discussions get unwieldy fast).

Motivation

The main goal is supporting interactive queries in presence of versioned state stores (KIP-889) in AK. For this KIP, the following query types are considered to be implemented. This KIP discusses single-key, single-timestamp queries. Other types of IQs are explained in the following KIPs (KIP-968 and KIP-969)  

Key Queries with single timestamp:

  1. single-key latest-value lookup
  2. single-key lookup with timestamp (upper) bound


Proposed Changes

In this KIP we propose a new field in KeyQuery to store the asOfTimestamp value. Moreover, the method asOf is added to the class in order to create key queries having asOfTimestamp value as well.  
Defining the latest() method is not needed since returning the latest value has been always the default assumption.

KeyQuery.java
package org.apache.kafka.streams.query; 

	/**
	* Specifies the upper inclusive bound for the key query. The key query returns the record
	* with the greatest timestamp <= asOfTimestamp
	* @param asOfTimestamp The upper inclusive bound for timestamp
	* @throws RuntimeException if the query already has a specified asOfTimestamp.
	*/
    public KeyQuery<K, V> asOf(Instant asOfTimestamp);


Examples....

The following example illustrates the use of the VersionedKeyQuery class to query a versioned state store.

final VersionedKeyQuery<Integer, Integer> query = VersionedKeyQuery.withKey(1).asOf(Instant.parse("2023-08-03T10:37:30.00Z");

final StateQueryRequest<ValueIterator<VersionedRecord<Integer>>> request =
        inStore("my_store").withQuery(query);

final StateQueryResult<ValueAndTimestamp<Integer>> result = kafkaStreams.query(request);


Compatibility, Deprecation, and Migration Plan

  • Since this is a completely new set of APIs, no backward compatibility concerns are anticipated. 
  • Since nothing is deprecated in this KIP, users have no need to migrate unless they want to.




  • No labels