[jira] [Updated] (KAFKA-15795) Support fetch(fromKey, toKey, from, to) to WindowRangeQuery and unify WindowKeyQuery and WindowRangeQuery
[
https://issues.apache.org/jira/browse/KAFKA-15795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hanyu Zheng updated KAFKA-15795:
Description:
KIP-997:
[https://cwiki.apache.org/confluence/display/KAFKA/KIP-997%3A++Support+fetch%28fromKey%2C+toKey%2C+from%2C+to%29+to+WindowRangeQuery+and+unify+WindowKeyQuery+and+WindowRangeQuery]
We aim to enhance the {{WindowRangeQuery}} by supporting a new method:
{{{}fetch(k{}}}ey{{{}From, keyT{}}}o{{{}, from, to){}}}. Currently,
{{WindowRangeQuery}} utilizes {{KeyValueIterator, V>
fetchAll(Instant timeFrom, Instant timeTo)}} for retrieving all key-value
pairs within a specified time range. However, we propose to use
{{KeyValueIterator, V> fetch(K keyFrom, K keyTo, Instant timeFrom,
Instant timeTo)}} instead. This new method will provide a
{{KeyValueIterator, V>}} that allows users to iterate over
windowed key-value pairs {{{, value>}}} , spanning the entire time
range.
With this new method, users can retrieve window sessions for specific keys,
rather than all keys, which enables a more targeted query. This is an
improvement over the {{fetchAll}} method, which only allows retrieval of all
key's window sessions without the ability to specify a range of keys.
Additionally, this enhancement also allows the {{WindowRangeQuery}} to support
{{WindowKeyQuery}} functionality. Users seeking to query window sessions for a
specific key can do so by setting {{keyFrom}} and {{keyTo}} to be equal. This
dual functionality provides more flexibility and efficiency in querying
windowed keys.
was:
KIP-997:
[https://cwiki.apache.org/confluence/display/KAFKA/KIP-997%3A++Support+fetch%28fromKey%2C+toKey%2C+from%2C+to%29+to+WindowRangeQuery+and+unify+WindowKeyQuery+and+WindowRangeQuery]
> Support fetch(fromKey, toKey, from, to) to WindowRangeQuery and unify
> WindowKeyQuery and WindowRangeQuery
> -
>
> Key: KAFKA-15795
> URL: https://issues.apache.org/jira/browse/KAFKA-15795
> Project: Kafka
> Issue Type: Improvement
> Components: streams
>Reporter: Hanyu Zheng
>Assignee: Hanyu Zheng
>Priority: Major
> Labels: kip
> Fix For: 3.7.0
>
>
> KIP-997:
> [https://cwiki.apache.org/confluence/display/KAFKA/KIP-997%3A++Support+fetch%28fromKey%2C+toKey%2C+from%2C+to%29+to+WindowRangeQuery+and+unify+WindowKeyQuery+and+WindowRangeQuery]
> We aim to enhance the {{WindowRangeQuery}} by supporting a new method:
> {{{}fetch(k{}}}ey{{{}From, keyT{}}}o{{{}, from, to){}}}. Currently,
> {{WindowRangeQuery}} utilizes {{KeyValueIterator, V>
> fetchAll(Instant timeFrom, Instant timeTo)}} for retrieving all key-value
> pairs within a specified time range. However, we propose to use
> {{KeyValueIterator, V> fetch(K keyFrom, K keyTo, Instant
> timeFrom, Instant timeTo)}} instead. This new method will provide a
> {{KeyValueIterator, V>}} that allows users to iterate over
> windowed key-value pairs {{{, value>}}} , spanning the entire
> time range.
> With this new method, users can retrieve window sessions for specific keys,
> rather than all keys, which enables a more targeted query. This is an
> improvement over the {{fetchAll}} method, which only allows retrieval of all
> key's window sessions without the ability to specify a range of keys.
> Additionally, this enhancement also allows the {{WindowRangeQuery}} to
> support {{WindowKeyQuery}} functionality. Users seeking to query window
> sessions for a specific key can do so by setting {{keyFrom}} and {{keyTo}}
> to be equal. This dual functionality provides more flexibility and efficiency
> in querying windowed keys.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (KAFKA-15795) Support fetch(fromKey, toKey, from, to) to WindowRangeQuery and unify WindowKeyQuery and WindowRangeQuery
[ https://issues.apache.org/jira/browse/KAFKA-15795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hanyu Zheng updated KAFKA-15795: Description: KIP-997: [https://cwiki.apache.org/confluence/display/KAFKA/KIP-997%3A++Support+fetch%28fromKey%2C+toKey%2C+from%2C+to%29+to+WindowRangeQuery+and+unify+WindowKeyQuery+and+WindowRangeQuery] was:KIP-997: > Support fetch(fromKey, toKey, from, to) to WindowRangeQuery and unify > WindowKeyQuery and WindowRangeQuery > - > > Key: KAFKA-15795 > URL: https://issues.apache.org/jira/browse/KAFKA-15795 > Project: Kafka > Issue Type: Improvement > Components: streams >Reporter: Hanyu Zheng >Assignee: Hanyu Zheng >Priority: Major > Labels: kip > Fix For: 3.7.0 > > > KIP-997: > [https://cwiki.apache.org/confluence/display/KAFKA/KIP-997%3A++Support+fetch%28fromKey%2C+toKey%2C+from%2C+to%29+to+WindowRangeQuery+and+unify+WindowKeyQuery+and+WindowRangeQuery] > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (KAFKA-15795) Support fetch(fromKey, toKey, from, to) to WindowRangeQuery and unify WindowKeyQuery and WindowRangeQuery
[ https://issues.apache.org/jira/browse/KAFKA-15795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hanyu Zheng updated KAFKA-15795: Description: KIP-997: > Support fetch(fromKey, toKey, from, to) to WindowRangeQuery and unify > WindowKeyQuery and WindowRangeQuery > - > > Key: KAFKA-15795 > URL: https://issues.apache.org/jira/browse/KAFKA-15795 > Project: Kafka > Issue Type: Improvement > Components: streams >Reporter: Hanyu Zheng >Assignee: Hanyu Zheng >Priority: Major > Labels: kip > Fix For: 3.7.0 > > > KIP-997: -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (KAFKA-15795) Support fetch(fromKey, toKey, from, to) to WindowRangeQuery and unify WindowKeyQuery and WindowRangeQuery
[ https://issues.apache.org/jira/browse/KAFKA-15795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hanyu Zheng reassigned KAFKA-15795: --- Assignee: Hanyu Zheng > Support fetch(fromKey, toKey, from, to) to WindowRangeQuery and unify > WindowKeyQuery and WindowRangeQuery > - > > Key: KAFKA-15795 > URL: https://issues.apache.org/jira/browse/KAFKA-15795 > Project: Kafka > Issue Type: Improvement > Components: streams >Reporter: Hanyu Zheng >Assignee: Hanyu Zheng >Priority: Major > Labels: kip > Fix For: 3.7.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (KAFKA-15795) Support fetch(fromKey, toKey, from, to) to WindowRangeQuery and unify WindowKeyQuery and WindowRangeQuery
Hanyu Zheng created KAFKA-15795: --- Summary: Support fetch(fromKey, toKey, from, to) to WindowRangeQuery and unify WindowKeyQuery and WindowRangeQuery Key: KAFKA-15795 URL: https://issues.apache.org/jira/browse/KAFKA-15795 Project: Kafka Issue Type: Improvement Components: streams Reporter: Hanyu Zheng Fix For: 3.7.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (KAFKA-15768) StateQueryResult#getOnlyPartitionResult should not throw for FailedQueryResult
[ https://issues.apache.org/jira/browse/KAFKA-15768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hanyu Zheng reassigned KAFKA-15768: --- Assignee: Hanyu Zheng > StateQueryResult#getOnlyPartitionResult should not throw for FailedQueryResult > -- > > Key: KAFKA-15768 > URL: https://issues.apache.org/jira/browse/KAFKA-15768 > Project: Kafka > Issue Type: Bug > Components: streams >Reporter: Matthias J. Sax >Assignee: Hanyu Zheng >Priority: Major > > Calling `StateQueryResult#getOnlyPartitionResult` crashes with an incorrect > `IllegalArgumentException` if the any result is a `FailedQueryResult` (and > even if there is only a single FailedQueryResult). > The issue is the internal `filter(r -> r.getResult() != 0)` step, that > blindly (and incorrectly) calls `getResult`. > Given the semantics of `getOnlyPartitionResult` we should not care if the > result is SuccessQueryResult or FailedQueryResult, but only check if there is > a single result or not. (The user has not means to avoid getting an exception > otherwise.) > Side-note: why does `FailedQueryResult#getResult` throw an > IllegalArgumentException (there is no argument passed into the method – it > should rather be an `IllegalStateException` – but I guess we would need a KIP > for this fix?) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (KAFKA-15629) proposal to introduce IQv2 Query Types: TimestampedKeyQuery and TimestampedRangeQuery
[ https://issues.apache.org/jira/browse/KAFKA-15629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hanyu Zheng updated KAFKA-15629: Fix Version/s: 3.7.0 > proposal to introduce IQv2 Query Types: TimestampedKeyQuery and > TimestampedRangeQuery > - > > Key: KAFKA-15629 > URL: https://issues.apache.org/jira/browse/KAFKA-15629 > Project: Kafka > Issue Type: Improvement > Components: streams >Reporter: Hanyu Zheng >Assignee: Hanyu Zheng >Priority: Major > Labels: kip > Fix For: 3.7.0 > > > KIP-992: > https://cwiki.apache.org/confluence/display/KAFKA/KIP-992%3A+Proposal+to+introduce+IQv2+Query+Types%3A+TimestampedKeyQuery+and+TimestampedRangeQuery > In the current IQv2 code, there are noticeable differences when interfacing > with plain-kv-store and ts-kv-store. Notably, the return type V acts as a > simple value for plain-kv-store but evolves into ValueAndTimestamp for > ts-kv-store, which presents type safety issues in the API. > Even if IQv2 hasn't gained widespread adoption, an immediate fix might bring > compatibility concerns. > This brings us to the essence of our proposal: the introduction of distinct > query types. One that returns a plain value, another for values accompanied > by timestamps. > While querying a ts-kv-store for a plain value and then extracting it is > feasible, it doesn't make sense to query a plain-kv-store for a > ValueAndTimestamp. > Our vision is for plain-kv-store to always return V, while ts-kv-store should > return ValueAndTimestamp. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (KAFKA-15527) Add reverseRange and reverseAll query over kv-store in IQv2
[ https://issues.apache.org/jira/browse/KAFKA-15527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hanyu Zheng updated KAFKA-15527: Fix Version/s: 3.7.0 > Add reverseRange and reverseAll query over kv-store in IQv2 > --- > > Key: KAFKA-15527 > URL: https://issues.apache.org/jira/browse/KAFKA-15527 > Project: Kafka > Issue Type: Improvement > Components: streams >Reporter: Hanyu Zheng >Assignee: Hanyu Zheng >Priority: Major > Labels: kip > Fix For: 3.7.0 > > > Add reverseRange and reverseAll query over kv-store in IQv2 > Update an implementation of the Query interface, introduced in [KIP-796: > Interactive Query > v2|https://cwiki.apache.org/confluence/display/KAFKA/KIP-796%3A+Interactive+Query+v2] > , to support reverseRange and reverseAll. > Use bounded query to achieve reverseRange and use unbounded query to achieve > reverseAll. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (KAFKA-15629) proposal to introduce IQv2 Query Types: TimestampedKeyQuery and TimestampedRangeQuery
[ https://issues.apache.org/jira/browse/KAFKA-15629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hanyu Zheng updated KAFKA-15629: Description: KIP-992: https://cwiki.apache.org/confluence/display/KAFKA/KIP-992%3A+Proposal+to+introduce+IQv2+Query+Types%3A+TimestampedKeyQuery+and+TimestampedRangeQuery In the current IQv2 code, there are noticeable differences when interfacing with plain-kv-store and ts-kv-store. Notably, the return type V acts as a simple value for plain-kv-store but evolves into ValueAndTimestamp for ts-kv-store, which presents type safety issues in the API. Even if IQv2 hasn't gained widespread adoption, an immediate fix might bring compatibility concerns. This brings us to the essence of our proposal: the introduction of distinct query types. One that returns a plain value, another for values accompanied by timestamps. While querying a ts-kv-store for a plain value and then extracting it is feasible, it doesn't make sense to query a plain-kv-store for a ValueAndTimestamp. Our vision is for plain-kv-store to always return V, while ts-kv-store should return ValueAndTimestamp. was: KIP-992: [https://cwiki.apache.org/confluence/display/KAFKA/KIP-992%3A+Proposal+to+introduce+IQv2+Query+Types%3A+TimestampKeyQuery+and+TimestampRangeQuery] In the current IQv2 code, there are noticeable differences when interfacing with plain-kv-store and ts-kv-store. Notably, the return type V acts as a simple value for plain-kv-store but evolves into ValueAndTimestamp for ts-kv-store, which presents type safety issues in the API. Even if IQv2 hasn't gained widespread adoption, an immediate fix might bring compatibility concerns. This brings us to the essence of our proposal: the introduction of distinct query types. One that returns a plain value, another for values accompanied by timestamps. While querying a ts-kv-store for a plain value and then extracting it is feasible, it doesn't make sense to query a plain-kv-store for a ValueAndTimestamp. Our vision is for plain-kv-store to always return V, while ts-kv-store should return ValueAndTimestamp. > proposal to introduce IQv2 Query Types: TimestampedKeyQuery and > TimestampedRangeQuery > - > > Key: KAFKA-15629 > URL: https://issues.apache.org/jira/browse/KAFKA-15629 > Project: Kafka > Issue Type: Improvement > Components: streams >Reporter: Hanyu Zheng >Assignee: Hanyu Zheng >Priority: Major > Labels: kip > > KIP-992: > https://cwiki.apache.org/confluence/display/KAFKA/KIP-992%3A+Proposal+to+introduce+IQv2+Query+Types%3A+TimestampedKeyQuery+and+TimestampedRangeQuery > In the current IQv2 code, there are noticeable differences when interfacing > with plain-kv-store and ts-kv-store. Notably, the return type V acts as a > simple value for plain-kv-store but evolves into ValueAndTimestamp for > ts-kv-store, which presents type safety issues in the API. > Even if IQv2 hasn't gained widespread adoption, an immediate fix might bring > compatibility concerns. > This brings us to the essence of our proposal: the introduction of distinct > query types. One that returns a plain value, another for values accompanied > by timestamps. > While querying a ts-kv-store for a plain value and then extracting it is > feasible, it doesn't make sense to query a plain-kv-store for a > ValueAndTimestamp. > Our vision is for plain-kv-store to always return V, while ts-kv-store should > return ValueAndTimestamp. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (KAFKA-15629) proposal to introduce IQv2 Query Types: TimestampedKeyQuery and TimestampedRangeQuery
[ https://issues.apache.org/jira/browse/KAFKA-15629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hanyu Zheng updated KAFKA-15629: Summary: proposal to introduce IQv2 Query Types: TimestampedKeyQuery and TimestampedRangeQuery (was: proposal to introduce IQv2 Query Types: TimeStampedKeyQuery and TimeStampedRangeQuery) > proposal to introduce IQv2 Query Types: TimestampedKeyQuery and > TimestampedRangeQuery > - > > Key: KAFKA-15629 > URL: https://issues.apache.org/jira/browse/KAFKA-15629 > Project: Kafka > Issue Type: Improvement > Components: streams >Reporter: Hanyu Zheng >Assignee: Hanyu Zheng >Priority: Major > Labels: kip > > KIP-992: > [https://cwiki.apache.org/confluence/display/KAFKA/KIP-992%3A+Proposal+to+introduce+IQv2+Query+Types%3A+TimestampKeyQuery+and+TimestampRangeQuery] > In the current IQv2 code, there are noticeable differences when interfacing > with plain-kv-store and ts-kv-store. Notably, the return type V acts as a > simple value for plain-kv-store but evolves into ValueAndTimestamp for > ts-kv-store, which presents type safety issues in the API. > Even if IQv2 hasn't gained widespread adoption, an immediate fix might bring > compatibility concerns. > This brings us to the essence of our proposal: the introduction of distinct > query types. One that returns a plain value, another for values accompanied > by timestamps. > While querying a ts-kv-store for a plain value and then extracting it is > feasible, it doesn't make sense to query a plain-kv-store for a > ValueAndTimestamp. > Our vision is for plain-kv-store to always return V, while ts-kv-store should > return ValueAndTimestamp. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (KAFKA-15629) proposal to introduce IQv2 Query Types: TimeStampedKeyQuery and TimeStampedRangeQuery
[ https://issues.apache.org/jira/browse/KAFKA-15629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hanyu Zheng updated KAFKA-15629: Summary: proposal to introduce IQv2 Query Types: TimeStampedKeyQuery and TimeStampedRangeQuery (was: proposal to introduce IQv2 Query Types: TimeStampKeyQuery and TimeStampRangeQuery) > proposal to introduce IQv2 Query Types: TimeStampedKeyQuery and > TimeStampedRangeQuery > - > > Key: KAFKA-15629 > URL: https://issues.apache.org/jira/browse/KAFKA-15629 > Project: Kafka > Issue Type: Improvement > Components: streams >Reporter: Hanyu Zheng >Assignee: Hanyu Zheng >Priority: Major > Labels: kip > > KIP-992: > [https://cwiki.apache.org/confluence/display/KAFKA/KIP-992%3A+Proposal+to+introduce+IQv2+Query+Types%3A+TimestampKeyQuery+and+TimestampRangeQuery] > In the current IQv2 code, there are noticeable differences when interfacing > with plain-kv-store and ts-kv-store. Notably, the return type V acts as a > simple value for plain-kv-store but evolves into ValueAndTimestamp for > ts-kv-store, which presents type safety issues in the API. > Even if IQv2 hasn't gained widespread adoption, an immediate fix might bring > compatibility concerns. > This brings us to the essence of our proposal: the introduction of distinct > query types. One that returns a plain value, another for values accompanied > by timestamps. > While querying a ts-kv-store for a plain value and then extracting it is > feasible, it doesn't make sense to query a plain-kv-store for a > ValueAndTimestamp. > Our vision is for plain-kv-store to always return V, while ts-kv-store should > return ValueAndTimestamp. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (KAFKA-15629) proposal to introduce IQv2 Query Types: TimeStampKeyQuery and TimeStampRangeQuery
[ https://issues.apache.org/jira/browse/KAFKA-15629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hanyu Zheng reassigned KAFKA-15629: --- Assignee: Hanyu Zheng > proposal to introduce IQv2 Query Types: TimeStampKeyQuery and > TimeStampRangeQuery > - > > Key: KAFKA-15629 > URL: https://issues.apache.org/jira/browse/KAFKA-15629 > Project: Kafka > Issue Type: Improvement > Components: streams >Reporter: Hanyu Zheng >Assignee: Hanyu Zheng >Priority: Major > > In the current IQv2 code, there are noticeable differences when interfacing > with plain-kv-store and ts-kv-store. Notably, the return type V acts as a > simple value for plain-kv-store but evolves into ValueAndTimestamp for > ts-kv-store, which presents type safety issues in the API. > Even if IQv2 hasn't gained widespread adoption, an immediate fix might bring > compatibility concerns. > This brings us to the essence of our proposal: the introduction of distinct > query types. One that returns a plain value, another for values accompanied > by timestamps. > While querying a ts-kv-store for a plain value and then extracting it is > feasible, it doesn't make sense to query a plain-kv-store for a > ValueAndTimestamp. > Our vision is for plain-kv-store to always return V, while ts-kv-store should > return ValueAndTimestamp. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (KAFKA-15629) proposal to introduce IQv2 Query Types: TimeStampKeyQuery and TimeStampRangeQuery
Hanyu Zheng created KAFKA-15629: --- Summary: proposal to introduce IQv2 Query Types: TimeStampKeyQuery and TimeStampRangeQuery Key: KAFKA-15629 URL: https://issues.apache.org/jira/browse/KAFKA-15629 Project: Kafka Issue Type: Improvement Components: streams Reporter: Hanyu Zheng In the current IQv2 code, there are noticeable differences when interfacing with plain-kv-store and ts-kv-store. Notably, the return type V acts as a simple value for plain-kv-store but evolves into ValueAndTimestamp for ts-kv-store, which presents type safety issues in the API. Even if IQv2 hasn't gained widespread adoption, an immediate fix might bring compatibility concerns. This brings us to the essence of our proposal: the introduction of distinct query types. One that returns a plain value, another for values accompanied by timestamps. While querying a ts-kv-store for a plain value and then extracting it is feasible, it doesn't make sense to query a plain-kv-store for a ValueAndTimestamp. Our vision is for plain-kv-store to always return V, while ts-kv-store should return ValueAndTimestamp. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (KAFKA-15569) Update test and add test cases in IQv2StoreIntegrationTest
[ https://issues.apache.org/jira/browse/KAFKA-15569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hanyu Zheng updated KAFKA-15569: Description: * Update test and add test cases in IQv2StoreIntegrationTest. * Originally, all key-value pairs were confined to a single window, with all data added at WINDOW_START. To improve our testing, we've expanded to multiple windows. * With a total of 10 records, keys ranging from 0 to 4 determine the designated partition for each message, either 0 or 1. Each consecutive pair of records, such as <0,0> and <0,1> or <1,2> and <1,3>, shares the same key. For instance, both <0,0> and <0,1> are directed to partition 0 due to their shared key '0', while pairs like <1,2> and <1,3>, having the key '1', are sent to partition 1. This pattern is consistent across all records. was: * Update test and add test cases in IQv2StoreIntegrationTest. * Originally, all key-value pairs were confined to a single window, with all data added at WINDOW_START. To improve our testing, we've expanded to multiple windows. * "We've added four key-value pairs at intervals starting from WINDOW_START: at WINDOW_START, WINDOW_START + 6min, WINDOW_START + 12min, and WINDOW_START + 18min. We're doing this to test the query methods of RangeQuery and WindowRangeQuery. > Update test and add test cases in IQv2StoreIntegrationTest > -- > > Key: KAFKA-15569 > URL: https://issues.apache.org/jira/browse/KAFKA-15569 > Project: Kafka > Issue Type: Test > Components: streams, unit tests >Reporter: Hanyu Zheng >Assignee: Hanyu Zheng >Priority: Major > > * Update test and add test cases in IQv2StoreIntegrationTest. > * Originally, all key-value pairs were confined to a single window, with all > data added at WINDOW_START. To improve our testing, we've expanded to > multiple windows. > * With a total of 10 records, keys ranging from 0 to 4 determine the > designated partition for each message, either 0 or 1. Each consecutive pair > of records, such as <0,0> and <0,1> or <1,2> and <1,3>, shares the same key. > For instance, both <0,0> and <0,1> are directed to partition 0 due to their > shared key '0', while pairs like <1,2> and <1,3>, having the key '1', are > sent to partition 1. This pattern is consistent across all records. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (KAFKA-15569) Update test and add test cases in IQv2StoreIntegrationTest
[ https://issues.apache.org/jira/browse/KAFKA-15569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hanyu Zheng updated KAFKA-15569: Description: * Update test and add test cases in IQv2StoreIntegrationTest. * Originally, all key-value pairs were confined to a single window, with all data added at WINDOW_START. To improve our testing, we've expanded to multiple windows. * "We've added four key-value pairs at intervals starting from WINDOW_START: at WINDOW_START, WINDOW_START + 6min, WINDOW_START + 12min, and WINDOW_START + 18min. We're doing this to test the query methods of RangeQuery and WindowRangeQuery. was: * Update test and add test cases in IQv2StoreIntegrationTest * Originally, all key-value pairs were confined to a single window, with all data added at WINDOW_START. To improve our testing, we've expanded to multiple windows * "We've added four key-value pairs at intervals starting from WINDOW_START: at WINDOW_START, WINDOW_START + 6min, WINDOW_START + 12min, and WINDOW_START + 18min. We're doing this to test the query methods of RangeQuery and WindowRangeQuery. > Update test and add test cases in IQv2StoreIntegrationTest > -- > > Key: KAFKA-15569 > URL: https://issues.apache.org/jira/browse/KAFKA-15569 > Project: Kafka > Issue Type: Test > Components: streams, unit tests >Reporter: Hanyu Zheng >Assignee: Hanyu Zheng >Priority: Major > > * Update test and add test cases in IQv2StoreIntegrationTest. > * Originally, all key-value pairs were confined to a single window, with all > data added at WINDOW_START. To improve our testing, we've expanded to > multiple windows. > * "We've added four key-value pairs at intervals starting from WINDOW_START: > at WINDOW_START, WINDOW_START + 6min, WINDOW_START + 12min, and WINDOW_START > + 18min. We're doing this to test the query methods of RangeQuery and > WindowRangeQuery. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (KAFKA-15569) Update test and add test cases in IQv2StoreIntegrationTest
[ https://issues.apache.org/jira/browse/KAFKA-15569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hanyu Zheng updated KAFKA-15569: Description: * Update test and add test cases in IQv2StoreIntegrationTest * Originally, all key-value pairs were confined to a single window, with all data added at WINDOW_START. To improve our testing, we've expanded to multiple windows * "We've added four key-value pairs at intervals starting from WINDOW_START: at WINDOW_START, WINDOW_START + 6min, WINDOW_START + 12min, and WINDOW_START + 18min. We're doing this to test the query methods of RangeQuery and WindowRangeQuery. was:Update test and add test cases in IQv2StoreIntegrationTest > Update test and add test cases in IQv2StoreIntegrationTest > -- > > Key: KAFKA-15569 > URL: https://issues.apache.org/jira/browse/KAFKA-15569 > Project: Kafka > Issue Type: Test > Components: streams, unit tests >Reporter: Hanyu Zheng >Assignee: Hanyu Zheng >Priority: Major > > * Update test and add test cases in IQv2StoreIntegrationTest > * Originally, all key-value pairs were confined to a single window, with all > data added at WINDOW_START. To improve our testing, we've expanded to > multiple windows > * "We've added four key-value pairs at intervals starting from WINDOW_START: > at WINDOW_START, WINDOW_START + 6min, WINDOW_START + 12min, and WINDOW_START > + 18min. We're doing this to test the query methods of RangeQuery and > WindowRangeQuery. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (KAFKA-15569) Update test and add test cases in IQv2StoreIntegrationTest
[ https://issues.apache.org/jira/browse/KAFKA-15569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hanyu Zheng reassigned KAFKA-15569: --- Assignee: Hanyu Zheng > Update test and add test cases in IQv2StoreIntegrationTest > -- > > Key: KAFKA-15569 > URL: https://issues.apache.org/jira/browse/KAFKA-15569 > Project: Kafka > Issue Type: Improvement >Reporter: Hanyu Zheng >Assignee: Hanyu Zheng >Priority: Major > > Update test and add test cases in IQv2StoreIntegrationTest -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (KAFKA-15569) Update test and add test cases in IQv2StoreIntegrationTest
Hanyu Zheng created KAFKA-15569: --- Summary: Update test and add test cases in IQv2StoreIntegrationTest Key: KAFKA-15569 URL: https://issues.apache.org/jira/browse/KAFKA-15569 Project: Kafka Issue Type: Improvement Reporter: Hanyu Zheng Update test and add test cases in IQv2StoreIntegrationTest -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (KAFKA-15527) Add reverseRange and reverseAll query over kv-store in IQv2
[ https://issues.apache.org/jira/browse/KAFKA-15527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hanyu Zheng updated KAFKA-15527: Description: Add reverseRange and reverseAll query over kv-store in IQv2 Update an implementation of the Query interface, introduced in [KIP-796: Interactive Query v2|https://cwiki.apache.org/confluence/display/KAFKA/KIP-796%3A+Interactive+Query+v2] , to support reverseRange and reverseAll. Use bounded query to achieve reverseRange and use unbounded query to achieve reverseAll. was:Add reverseRange and reverseAll query over kv-store in IQv2 > Add reverseRange and reverseAll query over kv-store in IQv2 > --- > > Key: KAFKA-15527 > URL: https://issues.apache.org/jira/browse/KAFKA-15527 > Project: Kafka > Issue Type: Improvement > Components: streams >Reporter: Hanyu Zheng >Assignee: Hanyu Zheng >Priority: Major > Labels: kip > > Add reverseRange and reverseAll query over kv-store in IQv2 > Update an implementation of the Query interface, introduced in [KIP-796: > Interactive Query > v2|https://cwiki.apache.org/confluence/display/KAFKA/KIP-796%3A+Interactive+Query+v2] > , to support reverseRange and reverseAll. > Use bounded query to achieve reverseRange and use unbounded query to achieve > reverseAll. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (KAFKA-15527) Add reverseRange and reverseAll query over kv-store in IQv2
Hanyu Zheng created KAFKA-15527: --- Summary: Add reverseRange and reverseAll query over kv-store in IQv2 Key: KAFKA-15527 URL: https://issues.apache.org/jira/browse/KAFKA-15527 Project: Kafka Issue Type: Improvement Reporter: Hanyu Zheng Add reverseRange and reverseAll query over kv-store in IQv2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (KAFKA-15527) Add reverseRange and reverseAll query over kv-store in IQv2
[ https://issues.apache.org/jira/browse/KAFKA-15527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hanyu Zheng reassigned KAFKA-15527: --- Assignee: Hanyu Zheng > Add reverseRange and reverseAll query over kv-store in IQv2 > --- > > Key: KAFKA-15527 > URL: https://issues.apache.org/jira/browse/KAFKA-15527 > Project: Kafka > Issue Type: Improvement >Reporter: Hanyu Zheng >Assignee: Hanyu Zheng >Priority: Major > > Add reverseRange and reverseAll query over kv-store in IQv2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
