mjsax commented on code in PR #13496:
URL: https://github.com/apache/kafka/pull/13496#discussion_r1160438018
##########
streams/src/main/java/org/apache/kafka/streams/kstream/internals/KTableKTableInnerJoin.java:
##########
@@ -153,11 +154,37 @@ public void init(final ProcessorContext<?, ?> context) {
@Override
public ValueAndTimestamp<VOut> get(final K key) {
- final ValueAndTimestamp<V1> valueAndTimestamp1 =
valueGetter1.get(key);
+ return computeJoin(key, valueGetter1::get, valueGetter2::get);
+ }
+
+ @Override
+ public ValueAndTimestamp<VOut> get(final K key, final long
asOfTimestamp) {
Review Comment:
> I don't understand why this is the property that we wish to preserve.
Because materialization vs non-materialization should be a non-functional
(ie, non semantical) change, but only a perf/resource footprint change. It's
like any other non-functional config change.
We decided to not correct older (potentially) incorrect result if
out-of-order data arrives. Thus, if we materialize the result as you point out
in you last paragraph, we would always us a potentially non-correct result on
lookup. Thus, we should do the same thing for the non-materialized case.
What actually raises an interesting question, as discussed in person: if the
result table is versioned, it's always materialized. And if its
not-materialized, it would actually always be non-versioned (because the user
has no way to tell us to make the result table versioned without forcing a
materialization.) And thus, if we do any `get()` on the non-versioned result
table, we would never do a `get(k,ts)` anyway, so maybe in practice there is no
issue?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: jira-unsubscr...@kafka.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
