Page History

...

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.

Although it's viable to issue a "plain value" query against While querying a ts-kv-store for a plain value and then unpack the return value, doing the reverse — launching a ValueAndTimestamp<V> query against extracting it is feasible, it doesn't make sense to query a plain-kv-store — seems illogicalfor a ValueAndTimestamp<V>.

Our vision is that  for plain-kv-store should to always return a plain V. However, for while ts-kv-store , there's a pronounced need for specialized query types. Ultimately, the user should only be required to define Vshould return ValueAndTimestamp<V>.

To address these concerns, we propose:

public final class KeyQuery<KTimestampKeyQuery<K, V> implements Query<V>
Query<ValueAndTimestamp<V>>

public final class TimestampKeyQuery<KTimestampRangeQuery<K, V> implements Query<KeyValueIterator<K, Query<ValueAndTimestamp<V>>ValueAndTimestamp<V>>>

Why introduce TimestampKeyQuery and TimestampRangeQuery? The primary motivation behind this is to ensure type safety and foster a clear distinction in our API. They bridge the difference between simple key-value stores and those integrated with timestamps, offering a more robust and intuitive querying mechanism.

...