[ https://issues.apache.org/jira/browse/FLINK-6849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16045498#comment-16045498 ]
mingleizhang commented on FLINK-6849: ------------------------------------- Here is a basic skeleton for the abstract class {{AbstractOperatorStateBackend}}. And At this moment, there is no specific implementation of the class. {code}/** * Base implementation of OperatorStateBackend. The state can be checkpointed * to streams using {@link #snapshot(long, long, CheckpointStreamFactory, CheckpointOptions)}. * */ public abstract class AbstractOperatorStateBackend implements OperatorStateBackend { /** * @see OperatorStateBackend */ @Override public <N, S extends State, T> S getOrCreateOperatorState(TypeSerializer<N> namespaceSerializer, StateDescriptor<S, T> stateDescriptor) throws Exception { return null; } /** * TODO: NOTE: This method does a lot of work caching / retrieving states just to update the namespace. * This method should be removed for the sake of namespaces being lazily fetched from the operator * state backend, or being set on the state directly. * * @see OperatorStateBackend * */ @Override public <N, S extends State> S getOperatorState(N namespace, TypeSerializer<N> namespaceSerializer, StateDescriptor<S, ?> stateDescriptor) throws Exception { return null; } }{code} > Refactor operator state backend and internal operator state hierarchy > --------------------------------------------------------------------- > > Key: FLINK-6849 > URL: https://issues.apache.org/jira/browse/FLINK-6849 > Project: Flink > Issue Type: Improvement > Components: State Backends, Checkpointing > Reporter: Tzu-Li (Gordon) Tai > > Currently, compared to the keyed state backends, the operator state backends, > as well as operator state interfaces, lacks proper hierarchy. > One issue with this lack of hierarchy is that the general concerns of > implementing state registration is different between the keyed and operator > backends (aside from what is naturally different, such as namespace and key > which is not relevant for the operator backend). For example, in the keyed > backend hierarchy, {{AbstractKeyedStateBackend}} has caches that shortcuts > re-accessing already registered state. This behaviour is missing in the > operator backend hierarchy, and for example needs to be explicitly handled by > the concrete {{DefaultOperatorStateBackend}} subclass implementation. > As of now, the need of a proper hierarchy also on the operator backend side > might not be that prominent, but will mostly likely become more prominent as > we wish to introduce more state structures for operator state (e.g. a > {{MapState}} for operator state has already been discussed a few times > already) as well as more options besides memory-backed operator state. -- This message was sent by Atlassian JIRA (v6.3.15#6346)