[jira] [Commented] (FLINK-5651) state backends: forbid Iterator#remove() from the Iterable returned by HeapListState#get()

["Nico Kruber (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/FLINK-5651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15839482#comment-15839482 ] 

Nico Kruber commented on FLINK-5651:
------------------------------------

Actually, it can be fine to use Iterator#remove() as long as the user does not reply on these changes in the backing store, i.e. to store the changes, ListState#clear() may be called afterwards and each elements needs to be added with ListState#add(value). Only together with queryable state, this may lead to race conditions but let's solve this for queryable state only in FLINK-5642

> state backends: forbid Iterator#remove() from the Iterable returned by HeapListState#get()
> ------------------------------------------------------------------------------------------
>
>                 Key: FLINK-5651
>                 URL: https://issues.apache.org/jira/browse/FLINK-5651
>             Project: Flink
>          Issue Type: Improvement
>          Components: State Backends, Checkpointing
>    Affects Versions: 1.2.0
>            Reporter: Nico Kruber
>            Assignee: Nico Kruber
>
> The idiom behind AppendingState#get() is to return a copy of the value behind or at least not to allow changes to the underlying state storage. However, the heap state backend returns the original list and thus is prone to changes.
> The returned Iterable offers Iterable#iterator() which in turn offers Iterator#remove() that would change the stored state. While we cannot efficiently block the user from modifying the objects in the list, we can at least prevent him from doing structural changes to the list by forbidding Iterator#remove() there.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)