This page is meant as a template for writing a KIP. To create a KIP choose Tools->Copy on this page and modify with your content and replace the heading with the next KIP number and a description of your issue. Replace anything in italics with your own description.
Current state: Adopted
Discussion thread: here
Please keep the discussion on the mailing list rather than commenting on the wiki (wiki discussions get unwieldy fast).
Provide an implementation of the
Query interface, introduced in KIP-796: Interactive Query v2 , to support session and window queries.
In this KIP we propose two new public classes:
This type used to search occurrences of keys in window stores in combination with IQv2. In particular the following mappings are established:
- WindowStore.fetch(K key, Instant timeFrom, Instant timeTo) ← WindowKeyQuery.withKeyAndWindowStartRange(key, from, to)
The query type is used to search per window aggregates of keys in window and session stores in combination with IQv2. In particular the following mappings are established:
- WindowStore.fetchAll(Instant timeFrom, Instant timeTo) ← WindowRangeQuery.withWindowStartRange(from, to)
- SessionStore.fetch(Bytes key) ← WindowRangeQuery.withKey(key)
There are multiple discussion points here:
- One reason we cannot use WindowKeyQuery to support SessionStore.fetch(key) is because SessionStore.fetch(key) returns a windowed key value iterator, KeyValueIterator<Windowed<Bytes>, byte>, whereas WindowKeyQuery is bound to Query<WindowStoreIterator<V>>.
- WindowRangeQuery does not currently support key ranges. We could add more cases here to get better coverage of WindowStore and SessionStore API. In this KIP, however, we focus on a subset of queries and defer support for additional cases to future KIPs.
The WindowKeyQuery class:
The WindowRangeQuery class:
The following example illustrates the use of the WindowKeyQuey class.
The following example illustrates the use of the WindowQuery class to query a window store.
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.