Hi Alieh,
I just realized that your KIP uses allKeys() and KIP-997 uses
withAllKeys() and the current RangeQuery uses withNoBounds(). We should
agree on one of those.
I am in favor of withAllKeys() but I am also fine with
withNoKeyBounds(). I just prefer the former because it is more concise
Hi Alieh,
I think using TimestampedRangeQuery to query the latest versions is
totally fine. If it is not, users will report it and we can add it then.
Best,
Bruno
On 12/11/23 6:22 PM, Alieh Saeedi wrote:
Thank you all.
I decided to remove the ordering from the KIP and maybe move it to the
su
Thank you all.
I decided to remove the ordering from the KIP and maybe move it to the
subsequent KIPs (based on user demand).
I skimmed over the discussion thread, but we still had an open question
about how a user can retrieve the `latest()` values. I think what Matthias
suggested (using `Timestam
Hi Alieh,
I think we do not have to restrict ourselves too much for the future
and complicate the implementation. The user can always store away and
sort, so we should only provide the ordering guarantee we can provide
efficiently, and we shouldn't restrict our future evolution too much
by this. I
Hi all,
I updated the KIP based on the changes made in the former KIP (KIP-968). So
with the `ResultOrder` enum, the class `MultiVersionedRangeQuery` had some
changes both in the defined fields and defined methods.
Based on the PoC PR, what we currently promise in the KIP about ordering
seems like
Thank you, Bruno and Matthias.
I updated the KIP as follows:
1. The one remaining `asOf` word in the KIP is removed.
2. Example 2 is updated. Thanks, Bruno for the correction.
Discussions and open questions
1. Yes, Bruno. We need `orderByKey()` and `orderByTimestamp()` as well.
Because the results
Great discussion. Seems we are making good progress.
I see advantages and disadvantages in splitting out a "single-ts
key-range" query type. I guess, the main question might be, what
use-cases do we anticipate and how common we believe they are?
We should also take KIP-992 (adding `Timestampe
Hi Alieh,
I like the examples!
1.
Some terms like `asOf` in the descriptions still need to be replaced in
the KIP.
2.
In your last e-mail you state:
"How can a user retrieve the latest value? We have the same issue with
kip-968 as well."
Why do we have the same issue in KIP-968?
If user
Thanks, Matthias and Bruno.
Here is a list of updates:
1. I changed the variable and method names as I did for KIP-968, as
follows:
- "fromTimestamp" -> fromTime
- "asOfTimestamp"-> toTime
- "from(instant)" -> fromTime(instant)"
- asOf(instant)"->toTime(instant)
2.
Thanks for the update.
To retrieve
the latest value(s), the user must call just the asOf method with the MAX
value (asOf(MAX)). The same applies to KIP-968. Do you think it is clumsy,
Matthias?
Well, in KIP-968 calling `asOf` and passing in a timestamp is optional,
and default
Thanks, Matthias and Bruno, for the feedback on KIP-969. Here is a summary
of the updates I made to the KIP:
1. I liked the idea of renaming methods as Matthias suggested.
2. I removed the allversions() method as I did in KIP-968. To retrieve
the latest value(s), the user must call just
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
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 t
13 matches
Mail list logo
