[
https://issues.apache.org/jira/browse/FLINK-5991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15953398#comment-15953398
]
ASF GitHub Bot commented on FLINK-5991:
---------------------------------------
Github user tzulitai commented on the issue:
https://github.com/apache/flink/pull/3508
@aljoscha @StefanRRichter Rebased on master to resolve conflicts.
Also, the follow-up commits addresses the following:
1. Remove / deprecate the Java serialization shortcuts. We have some
connectors that use the deprecated shortcut method, but I think since changing
those will require some more involved migration work, I propose to fix those as
a separate JIRA / PR.
2. According to Stephan's suggestion, refine the current naming of the
operator state methods. `getOperatorState` is renamed to `getListState`, and
the new union state is named as `getUnionListState`.
Further question regarding deprecating Java serialization shortcuts: do we
then also have a cause to deprecate the `ListCheckpointed` interface, since
that itself is a shortcut also?
> Expose Broadcast Operator State through public APIs
> ---------------------------------------------------
>
> Key: FLINK-5991
> URL: https://issues.apache.org/jira/browse/FLINK-5991
> Project: Flink
> Issue Type: New Feature
> Components: DataStream API, State Backends, Checkpointing
> Reporter: Tzu-Li (Gordon) Tai
> Assignee: Tzu-Li (Gordon) Tai
> Fix For: 1.3.0
>
>
> The broadcast operator state functionality was added in FLINK-5265, it just
> hasn't been exposed through any public APIs yet.
> Currently, we have 2 streaming connector features for 1.3 that are pending on
> broadcast state: rescalable Kinesis / Kafka consumers with shard / partition
> discovery (FLINK-4821 & FLINK-4022). We should consider exposing broadcast
> state for the 1.3 release also.
> This JIRA also serves the purpose to discuss how we want to expose it.
> To initiate the discussion, I propose:
> 1. For the more powerful {{CheckpointedFunction}}, add the following to the
> {{OperatorStateStore}} interface:
> {code}
> <S> ListState<S> getBroadcastOperatorState(ListStateDescriptor<S>
> stateDescriptor);
> <T extends Serializable> ListState<T>
> getBroadcastSerializableListState(String stateName);
> {code}
> 2. For a simpler {{ListCheckpointed}} variant, we probably should have a
> separate {{BroadcastListCheckpointed}} interface.
> Extending {{ListCheckpointed}} to let the user define either the list state
> type of either {{PARTITIONABLE}} or {{BROADCAST}} might also be possible, if
> we can rely on a contract that the value doesn't change. Or we expose a
> defining method (e.g. {{getListStateType()}}) that is called only once in the
> operator. This would break user code, but can be considered because it is
> marked as {{PublicEvolving}}.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
