[ 
https://issues.apache.org/jira/browse/FLINK-6849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Flink Jira Bot updated FLINK-6849:
----------------------------------
      Labels: auto-deprioritized-major auto-deprioritized-minor  (was: 
auto-deprioritized-major stale-minor)
    Priority: Not a Priority  (was: Minor)

This issue was labeled "stale-minor" 7 days ago and has not received any 
updates so it is being deprioritized. If this ticket is actually Minor, please 
raise the priority and ask a committer to assign you the issue or revive the 
public discussion.


> 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: Runtime / State Backends
>            Reporter: Tzu-Li (Gordon) Tai
>            Priority: Not a Priority
>              Labels: auto-deprioritized-major, auto-deprioritized-minor
>
> 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
(v8.20.1#820001)

Reply via email to