You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jira@kafka.apache.org by "Guozhang Wang (JIRA)" <ji...@apache.org> on 2019/02/08 01:28:00 UTC
[jira] [Resolved] (KAFKA-7872) Consider allowing transformations on
GlobalKTable before materialization
[ https://issues.apache.org/jira/browse/KAFKA-7872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Guozhang Wang resolved KAFKA-7872.
----------------------------------
Resolution: Duplicate
> Consider allowing transformations on GlobalKTable before materialization
> ------------------------------------------------------------------------
>
> Key: KAFKA-7872
> URL: https://issues.apache.org/jira/browse/KAFKA-7872
> Project: Kafka
> Issue Type: Improvement
> Components: streams
> Reporter: Guozhang Wang
> Priority: Major
>
> Current GlobalKTable's interface does not allow any transformations on itself:
> {code}
> public interface GlobalKTable<K, V> {
> /**
> * Get the name of the local state store that can be used to query this {@code GlobalKTable}.
> *
> * @return the underlying state store name, or {@code null} if this {@code GlobalKTable} cannot be queried.
> */
> String queryableStoreName();
> }
> {code}
> This limits use cases such that users want to read the source topic, and do some filtering / value transformations / reformatting etc before materialize it to the backing state stores for further operations like joins. On the other hand, for KTable today we already allow the source KTable to be filtered / value-mapped etc which would, behind the scene, apply those applications on the fly before materializing to the state stores.
> We should consider adding such functionalities for GlobalKTable as well.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)