Versions Compared

Old Version 7

changes.mady.by.user Almog Gavra

Saved on

compared with

New Version 8

changes.mady.by.user Almog Gavra

Saved on

Key

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

...

Code Block
languagejava
titleDSLStoreProvider.java
public interface StoreTypeSpec {

    KeyValueBytesStoreSupplier keyValueStore(final KeyValueSupplierParameters params);

    WindowBytesStoreSupplier windowStore(final WindowSupplierParameters params);

    SessionBytesStoreSupplier sessionStore(final SessionSupplierParameters params);
}

// the below are all "struct"-like classes with the following fields
class KeyValueSupplierParametersKeyValueSupplierParams(String name);
class WindowSupplierParametersWindowSupplierParams(String name, Duration retentionPeriod, Duration windowSize, boolean retainDuplicates, EmityStrategyEmitStrategy emitStrategy);
class SessionSupplierParametersSessionSupplierParams(String name, Duration retentionPeriod, EmityStrategyEmitStrategy emitStrategy);


Info

Note on Evolving API: a concern raised on KIP-591 about having such an interface is that the increased API surface area would mean introducing new store implementations would cause custom state store implementations to throw compile time errors. Introducing the *Parameters classes will prevent such issues unless an entirely new store type is added.

If an entirely new state store type (beyond KV/Windowed/Session) is added - I think it is valid to have new store types have a default implementation that throws new UnsupportedOperationException() as it is unlikely that users that specify a custom state store as the default will want a different (e.g. ROCKS_DB) store created without them knowing. This also seems unlikely since these three have been there for many years and they've been the only three for that duration.

...