KAFKA-14491: [12/N] Relax requirement that KTable stores must be TimestampedKVStores by vcrfxia · Pull Request #13264 · apache/kafka

vcrfxia · 2023-02-16T21:27:47Z

As part of introducing versioned key-value stores in KIP-889, we want to lift the existing DSL restriction that KTable stores are always TimestampedKeyValueStores to allow for KTable stores which are VersionedKeyValueStores instead. This PR lifts the restriction by replacing raw usages of TimestampedKeyValueStore with a new KeyValueStoreWrapper which supports either TimestampedKeyValueStore or VersionedKeyValueStore. (Until versioned stores are actually exposed to users in a follow-up PR, all KTables stores will continue to be TimestampedKeyValueStores.)

The loss of type-safety from StoreBuilder<TimestampedKeyValueStore<K, VR>> to StoreBuilder<?> is unfortunate but necessary in order to allow for top-level VersionedKeyValueStores, so that users may access versioned stores for use in transform() operations and interactive queries.

Committer Checklist (excluded from commit message)

Verify design and implementation
Verify test coverage and CI build status
Verify documentation (including upgrade notes)

…ores

mjsax · 2023-02-24T22:36:45Z

+            // next try versioned store
+            versionedStore = context.getStateStore(storeName);
+        } catch (final ClassCastException e) {
+            throw new InvalidStateStoreException("KTable source state store must implement either TimestampedKeyValueStore or VersionedKeyValueStore.");


Should we include the type of the store we found in the error message?

mjsax · 2023-02-24T22:42:27Z

+        throw new IllegalStateException("KeyValueStoreWrapper must be initialized with either timestamped or versioned store");
+    }
+
+    public StateStore getStore() {


Do we really need this method? It seem whoever uses KeyValueStoreWrapper can keep a handle of the store themselves?

If we think it's convenient to keep this helper, should we add a Store store member variable, and implement this one a simple return store? (Similar for name(), init() etc below?)

If we don't get the correct stores passed into the constructor we fail anyway, and it seem a lot of unncessary boiler plate code in those "non-functional helpers"

I prefer to keep this method because otherwise either (1) both the caller and KeyValueStoreWrapper would have to call context.getStateStore(storeName) when the caller needs the state store in addition to the wrapper, which feels redundant, or (2) if we avoid the duplication by not having the wrapper call context.getStateStore(storeName) then the caller would always have to call context.getStateStore(storeName) even when it doesn't need the state store itself (only the wrapper), which feels clunky.

If we think it's convenient to keep this helper, should we add a Store store member variable, and implement this one a simple return store?

We can do that. Inside KeyValueStoreWrapper we still have to track whether the store is a timestamped store or a versioned store, in order to use the appropriate interfaces in put() and get(). I could introduce a private enum for this purpose; feels a little overkill but I can't think of anything better. I'll go ahead and make the change.

My proposal was actually to have three member, the previously existing KeyValueStore keyValueStore, VersionedStore versionStore and a new Store store. So we just simplify the code for the case when we don't care about the store type, but when we care we check if keyValueStore != null or versionStore != null and do the right thing.

Sorry for not explaining it good enough -- using an enum works, too, I guess, but also tend to agree it a little overkill. But you made the change already... So maybe also not worth to revert it again to sue KeyValueStore keyValueStore and VersionedStore versionStore as you did originally.

The only question (by might be pre-mature optimization): we know need to cast on very single get/put call using the enum. Sounds like more overhead that using KeyValueStore keyValueStore/VersionedStore versionStoreand check fornull` as originally?

Yeah, your point about casting overhead is valid. I had hoped it'd be fairly minimal, but that's moot now since I went ahead and updated the PR to use your proposal (three store pointers) in response to your comment about test failures (see below).

mjsax · 2023-02-24T22:45:05Z

+    }
+
+    @Test
+    public void shouldGetTimestampedStore() {


If we add the Store store member, it seem we can cut 50% of the tests below?

I added the Store store member which indeed simplified the code in KeyValueStoreWrapper, but have chosen to keep these tests here for coverage.

mjsax · 2023-02-24T22:48:24Z

     * @return  StoreBuilder
     */
-    public StoreBuilder<TimestampedKeyValueStore<K, V>> materialize() {
+    public StoreBuilder<?> materialize() {


Why can't we keep the generic typer here? I understand that we need to make it <?> in KTableImpl (and the "graph node" code below) but not sure why we need <?> here, too?

You're right; we don't need to make this change yet but it will be required as part of the changes in #13274. I can back it out here and reapply in #13274 instead.

I we need it later, it's fine to do it right away. Maybe a little cleaner from a "commit history" POV do only to it later.

vcrfxia

Thanks for your review, @mjsax ! Incorporated your suggestions into the latest commit.

vcrfxia · 2023-02-25T00:19:14Z

     * @return  StoreBuilder
     */
-    public StoreBuilder<TimestampedKeyValueStore<K, V>> materialize() {
+    public StoreBuilder<?> materialize() {


You're right; we don't need to make this change yet but it will be required as part of the changes in #13274. I can back it out here and reapply in #13274 instead.

vcrfxia · 2023-02-25T00:35:55Z

+        throw new IllegalStateException("KeyValueStoreWrapper must be initialized with either timestamped or versioned store");
+    }
+
+    public StateStore getStore() {


I prefer to keep this method because otherwise either (1) both the caller and KeyValueStoreWrapper would have to call context.getStateStore(storeName) when the caller needs the state store in addition to the wrapper, which feels redundant, or (2) if we avoid the duplication by not having the wrapper call context.getStateStore(storeName) then the caller would always have to call context.getStateStore(storeName) even when it doesn't need the state store itself (only the wrapper), which feels clunky.

If we think it's convenient to keep this helper, should we add a Store store member variable, and implement this one a simple return store?

We can do that. Inside KeyValueStoreWrapper we still have to track whether the store is a timestamped store or a versioned store, in order to use the appropriate interfaces in put() and get(). I could introduce a private enum for this purpose; feels a little overkill but I can't think of anything better. I'll go ahead and make the change.

vcrfxia · 2023-02-25T00:39:02Z

+    }
+
+    @Test
+    public void shouldGetTimestampedStore() {


I added the Store store member which indeed simplified the code in KeyValueStoreWrapper, but have chosen to keep these tests here for coverage.

vcrfxia · 2023-02-25T01:14:18Z

+    public KeyValueStoreWrapper(final ProcessorContext<?, ?> context, final String storeName) {
+        store = context.getStateStore(storeName);
+
+        if (store instanceof TimestampedKeyValueStore) {


It's interesting that these checks don't verify the generic types (i.e., K and V) but IIUC the code in ProcessorContextImpl#getStateStore() for casting state stores to the requested type does not check generic types either, so I don't believe there's a visible change in behavior here.

I think this is fine. -- Even if we have the cast as in the original code, I don't think it would be safer. The compile check cannot verify the generic types anyway, because getStateStore does not contain any information about it -- and at runtime, the generic types are gone and the actually "cast" if necessary from Object to K (or V) would happen somewhere else in the code.

mjsax · 2023-03-02T02:21:53Z

There is test failures. Could it be related to this PR?

org.apache.kafka.streams.kstream.internals.KTableKTableInnerJoinTest.shouldLogAndMeterSkippedRecordsDueToNullLeftKey
java.lang.NullPointerException: Cannot invoke "Object.getClass()" because "this.store" is null

If not related to this PR, we should check JIRA if there is already a flaky test ticket, and if not create one.

vcrfxia · 2023-03-02T07:19:23Z

There is test failures. Could it be related to this PR?

Good catch. These failures only appeared when I switched from the original try-catch approach for casting stores to either TimestampedKeyValueStore or VersionedKeyValueStore, to fetching the store as a generic StateStore and then performing instanceof checks. The failures happened because the unit tests use a mock context which returns null for the state store, which failed the instanceof checks. I'm pretty sure in the actual code (non-mocked contexts) it's not possible for context.getStateStore() to return null and therefore this "issue" is limited to unit tests only, but I've updated the PR to return to the original try-catch approach for casting in order to be safe (and in light of your other comment above, regarding type casts on every put/get call).

vcrfxia added 3 commits February 16, 2023 13:26

relax requirement that KTable stores are always TimestampedKeyValueSt…

6459bf0

…ores

checkstyle

ffb2dc8

checkstyle

d19140e

This was referenced Feb 17, 2023

KAFKA-14491: [11/N] Add metered wrapper for versioned stores #13252

Merged

KAFKA-14491: [13/N] Add versioned store builder and materializer #13274

Merged

mjsax added streams kip Requires or implements a KIP labels Feb 24, 2023

mjsax reviewed Feb 24, 2023

View reviewed changes

review feedback

d75cab4

vcrfxia commented Feb 25, 2023

View reviewed changes

review feedback

3c15f65

unexpected store type fix

b354ee0

mjsax merged commit 517b5d2 into apache:trunk Mar 2, 2023

vcrfxia deleted the kip-889-ktable-stores branch March 2, 2023 22:18

Uh oh!

Conversation

vcrfxia commented Feb 16, 2023

Committer Checklist (excluded from commit message)

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mjsax Mar 2, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mjsax Feb 24, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mjsax Mar 2, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

vcrfxia left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mjsax Mar 2, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mjsax commented Mar 2, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

vcrfxia commented Mar 2, 2023

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

mjsax Mar 2, 2023 •

edited

Loading

mjsax Feb 24, 2023 •

edited

Loading

mjsax Mar 2, 2023 •

edited

Loading

mjsax Mar 2, 2023 •

edited

Loading

mjsax commented Mar 2, 2023 •

edited

Loading