mjsax commented on code in PR #21237:
URL: https://github.com/apache/kafka/pull/21237#discussion_r2814329747
##########
streams/src/main/java/org/apache/kafka/streams/kstream/KGroupedStream.java:
##########
@@ -383,7 +383,8 @@ KTable<K, V> reduce(final Reducer<V> reducer,
* Thus, {@code aggregate(Initializer, Aggregator)} can be used to compute
aggregate functions like
* count (cf. {@link #count()}).
* <p>
- * The default value serde from config will be used for serializing the
result.
+ * The <b>default value serde</b> from the config will be used for
serializing the result.
+ * The <b>key serde</b> is derived from the upstream operator (i.e., the
one used for the grouping).
Review Comment:
Nit: might be better to describe key serde before value serde, as we process
key-value pairs (not value-key pairs); it seems more logical this way.
I also don't think that there is any need to use `<b>` markup.
Also, serde inheritance is not just about the direct upstream operators, but
the whole chain. For example:
```
builders.stream(..., Consumed.with(keySerde,
valueSerde)).groupByKey().aggregate(...)
```
For this case, `groupBykey()` does not define any serdes, but only the
upstream `.stream(...)` operator does. Both `groupByKey()` and `aggregate()`
inherit the upstream key serde -- only the value serde cannot be re-used,
because `aggregate` defines a new value type. However, for the `reduce()` case
(which cannot change the type of the value), also the value serde would be
inherited.
I think we need to be more clear about this.
--
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
