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