Versions Compared

Old Version 1

changes.mady.by.user Luke Chen

Saved on

compared with

New Version 2

changes.mady.by.user Luke Chen

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Compatibility, Deprecation, and Migration Plan

  • What impact (if any) will there be on existing users?
  • If we are changing behavior how will we phase out the older behavior?
  • If we need special migration tools, describe them here.
  • When will we remove the existing behavior?

Rejected Alternatives

This change is completely backward compatible.

Rejected Alternatives

Extended from KIP-763: Range queries with open endpoints

Adding new method methods for unbounded range queries

One alternative to the proposed solution is to add new methods for querying unbounded ranges:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

/**
 * Get an iterator over all keys less than or equal to the key passed in.
 * @param to The last key that could be in the range
 * @return The iterator for this range.
 * @throws NullPointerException If null is used for to.
 */
default KeyValueIterator<K, V> rangeUntil(K to) { throw new UnsupportedOperationException(); }
 
/**
 * Get an iterator over all keys greater than or equal to the key passed in.
 * @param from The first key that could be in the range
 * @return The iterator for this range.
 * @throws NullPointerException If null is used for from.
 */
default KeyValueIterator<K, V> rangeFrom(K from) { throw new UnsupportedOperationException();

We rejected this solution because of two reasons. First, because of the nested architecture of the Kafka streams state stores, adding new methods to the state store interface requires modifications to more than a dozen of interfaces which increases the potential for bugs and makes code maintenance and testing more difficult. These issues are further amplified if in the future we want to add variations to those range calls, such as the ability to configure one of the bounds to be inclusive or exclusive.

Modify existing range interface

Yet another solution would be replace the existing range interface with something more powerful that can support different types of range queries with a single method. An example of such an interface is given blow.

1
2
3
4
5
6
7
8
9
10

void range(Range<K> range)
 
class Range<K> {
  K from;
  K to;
  ...
  static <K> from(K key) ...
  static <K> until(K key) ..
  // etc
}

While a solution like this would be the cleanest, it would require that we deprecate the old range interface and migrate existing code to the new interface. Compared to the solution proposed in this KIP, which does not require modifications to the interface and no migration is needed, we felt that making bigger changes to the range interface is not necessary at this pointIf there are alternative ways of accomplishing the same thing, what were they? The purpose of this section is to motivate why the design is the way it is and not some other way.