[
https://issues.apache.org/jira/browse/KAFKA-5648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16103319#comment-16103319
]
Matthias J. Sax commented on KAFKA-5648:
----------------------------------------
The issue is, if one implements old {{Merger}} and does a hotswap of the
Streams library without recompiling the code. The class ID will not match as
the class hierarchy did change. The existing class would only implement
{{Merger}} but not {{Merger extends Aggregator}}.
You are right, that if one recompiles the code, not code change is required to
pass the build.
> make Merger extend Aggregator
> -----------------------------
>
> Key: KAFKA-5648
> URL: https://issues.apache.org/jira/browse/KAFKA-5648
> Project: Kafka
> Issue Type: New Feature
> Components: streams
> Affects Versions: 0.11.0.0
> Reporter: Clemens Valiente
> Assignee: Clemens Valiente
> Priority: Minor
>
> Hi,
> I suggest that Merger<K,V> should extend Aggregator<K,V,V>.
> reason:
> Both classes usually do very similar things. A merger takes two sessions and
> combines them, an aggregator takes an existing session and aggregates new
> values into it.
> in some use cases it is actually the same thing, e.g.:
> <null, log_event> -> .map() to <session_id,SingletonList<log_event>> ->
> .groupByKey().aggregate() to <session_id, List<log_event>>
> In this case both merger and aggregator do the same thing: take two lists and
> combine them into one.
> With the proposed change we could pass the Merger as both the merger and
> aggregator to the .aggregate() method and keep our business logic within one
> merger class.
> Or in other words: The Merger is simply an Aggregator that happens to
> aggregate two objects of the same class
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
