[ 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)