Thanks for updating the KIP.
Not sure if I agree or not with Bruno's idea to split the query types
further? In the end, we split them only because there is three different
return types: single value, value-iterator, key-value-iterator.
What do we gain by splitting out single-ts-range-key? In the end, for
range-ts-range-key the proposed class is necessary and is a superset
(one can set both timestamps to the same value, for single-ts lookup).
The mentioned simplification might apply to "single-ts-range-key" but I
don't see a simplification for the proposed (and necessary) query type?
On the other hand, I see an advantage of a single-ts-range-key for
querying over the "latest version" with a range of keys. For a
single-ts-range-key query, this it would be the default (similar to
VersionedKeyQuery with not asOf-timestamped defined).
In the current version of the KIP, (if we agree that default should
actually return "all versions" not "latest" -- this default was
suggested by Bruno on KIP-968 and makes sense to me, so we would need to
have the same default here to stay consistent), users would need to pass
in `from(Long.MAX).to(Long.MAX)` (if I got this right) to query the
latest point in time only, what seems to be clumsy? Or we could add a
`lastestKeyOnly` option to `MultiVersionedRangeQuery`, but it does seems
a little clumsy, too.
The overall order of the returned records is by Key
I assume, results are returned by timestamp for each key. The KIP should
be explicit about it.
To be very explicit, should we rename the methods to specify the key bound?
- withRange -> withKeyRange
- withLowerBound -> withLowerKeyBound
- withUpperBound -> withUpperKeyBound
- withNoBounds -> allKeys (or withNoKeyBounds, but we use
`allVersions` and not `noTimeBound` and should align the naming?)
-Matthias
On 9/6/23 5:25 AM, Bruno Cadonna wrote:
Hi Alieh,
Thanks for the KIP!
One high level comment/question:
I assume you separated single key queries into two classes because
versioned key queries return a single value and multi version key
queries return iterators. Although, range queries always return
iterators, it would make sense to also separate range queries for
versioned state stores into range queries that return one single version
of the keys within a range and range queries that return multiple
version of the keys within a range, IMO. That would reduce the
meaningless combinations.
WDYT?
Best,
Bruno
On 8/16/23 8:01 PM, Alieh Saeedi wrote:
Hi all,
I splitted KIP-960
<https://cwiki.apache.org/confluence/display/KAFKA/KIP-960%3A+Support+single-key_single-timestamp+interactive+queries+%28IQv2%29+for+versioned+state+stores>
into
three separate KIPs. Therefore, please continue discussions about range
interactive queries here. You can see all the addressed reviews on the
following page. Thanks in advance.
KIP-969: Support range interactive queries (IQv2) for versioned state
stores
<https://cwiki.apache.org/confluence/display/KAFKA/KIP-969%3A+Support+range+interactive+queries+%28IQv2%29+for+versioned+state+stores>
I look forward to your feedback!
Cheers,
Alieh
