[
https://issues.apache.org/jira/browse/FLINK-6849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16040460#comment-16040460
]
Stefan Richter commented on FLINK-6849:
---------------------------------------
I agree in general, because this was clear from the beginning that we need
might have other implementations of the `OperatorStateBackend` interface.
However, I think we should only start doing this change when we already have a
concrete plan to introduce more implementations, e.g. based on RocksDB. I would
also suggest that before starting this, we also spend some thoughts on the
relationship of operator state and keyed state in general and if they could not
be based on one common backend abstraction. For now, is there already any
concrete need to do changes (other than cosmetical)?
> 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)
