I don't think ordering is guaranteed in the internal implementation, to the best of my knowledge. I agreed with Aljoscha, if there is no clear definition of ordering, it is assumed to be not preserved by default.
-- Rong On Thu, Sep 13, 2018 at 7:30 PM 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> 于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> 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> 于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 >>> >>> >>> >>
