...
Code Block |
---|
/** * Implementations of this will provide the ability to wrap a given StateStore * with or without caching/loggging etc. */ public interface StateStoreBuilder<T extends StateStore> { StateStoreBuilder<T> withCachingEnabled(); StateStoreBuilder<T> withCachingDisabled(); StateStoreBuilder<T> withLoggingEnabled(Map<String, String> config); StateStoreBuilder<T> withLoggingDisabled(); T build(); } |
Proposed Changes
Describe the new thing you want to do in appropriate detail. This may be fairly extensive and have large subsections of its own. Or it may be a few sentences. Use judgement based on the scope of the changeAdd the above methods, interfaces, classes to the DSL. Deprecate the existing overloads.
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
...
- None - we will deprecate the existing methods so that existing users can continue until they decide to change
Rejected Alternatives
- Using a more fluent api: this approach always results in intermediate stages that require a final build or apply call to create the underlying KStream/KTable etc. We felt that this wasn't quite right.
- Builder for all a params: Rather than specifying the required params and optional params separately we could make each method take a Builder that has all of the params. It was felt that this is a but onerous for users that just want to use the required params and don't care about the options