Hi all,

Flink does not provide any guarantees about the order of the elements in a list 
and it leaves it to the state-backends.

This means that semantics between different backends may differ, and even if 
something holds now for one of them, if 
RocksDB or a filesystem decides to change its semantics, then any assumptions 
will not hold anymore.

So I would recommend to program under the assumption that no order guarantees 
are provided.

Cheers,
Kostas

> On Sep 14, 2018, at 4:30 AM, vino yang <yanghua1...@gmail.com> wrote:
> 
> Hi Aljoscha,
> 
> Regarding window merging, as you said, it's not clear, because Flink does 
> some internal work. 
> But if it's just for the user, isn't it clear without any internal 
> operations? I think if the user explicitly uses it, it should conform to the 
> basic List semantics. Otherwise why define it instead of using SetListState 
> directly?
> 
> Thanks, vino.
> 
> Aljoscha Krettek <aljos...@apache.org <mailto:aljos...@apache.org>> 
> 于2018年9月13日周四 下午10:42写道:
> Hi,
> 
> this is not clearly defined anywhere, and I was always working under the 
> assumption that the order is not preserved. This potentially allows more 
> optimizations by the system, and for example in case of merging windows we 
> don't know the order of elements in a ListState after a merge.
> 
> Best,
> Aljoscha
> 
>> On 6. Sep 2018, at 08:19, vino yang <yanghua1...@gmail.com 
>> <mailto:yanghua1...@gmail.com>> wrote:
>> 
>> Hi Alexey,
>> 
>> The answer is Yes, which preserves the semantics of the List's order of 
>> elements.
>> 
>> Thank, vino.
>> 
>> Alexey Trenikhun <yen...@msn.com <mailto:yen...@msn.com>> 于2018年9月6日周四 
>> 上午10:55写道:
>> Hello,
>> Does keyed managed ListState<T> preserve elements order, for example if I 
>> call listState.add(e1); listState.add(e2); listState.add(e3); , does 
>> ListState<T> guarantee that listState.get() will return elements in order 
>> they were added (e1, e2, e3)
>> 
>> Alexey
>> 
>> 
> 

Reply via email to