Actually, this is not a bug. The "global" namespace is for storage that is per-key but not related to any window. So it is explicitly a separate domain from the global window. It is a concept just for runner implementors, not really part of the model and definitely not user facing.
Kenn On Fri, Aug 16, 2019 at 4:22 AM Jan Lukavský <je...@seznam.cz> wrote: > Hi Max, > > I can do that, but the correct solution seems not to be that easy. I > think that changing either variant is a breaking change - the new > version will not correctly load from previous version of state > checkpoint. That is a serious problem, because pipelines would not be > easily upgradable. It looks a little "better" to change > StateNamespaces.global(), as it is used less often, but it is not a good > solution either. A correct solution would be somewhat complex I'm afraid > - i.e. in namespace '/' try to fetch '/' first, and if it is not > present, fetch '//'. Use '/' for storing. > > Any other ideas? > > Jan > > On 8/16/19 12:14 PM, Maximilian Michels wrote: > > Hi Jan, > > > > I don't think this is intentional. It looks like an inconsistency which > > could result in unexpected behavior in UDFs, e.g. when storing state and > > timers. > > > > Want to open a PR? > > > > -Max > > > > On 12.08.19 14:22, Jan Lukavský wrote: > >> Hi, > >> > >> I noticed, that StateNamespaces.global() generates a different stringKey > >> than StateNamespaces.window(GlobalWindowCoder, GlobalWindow). In the > >> first case, the stringKey will be simply '/', in the other it will be > >> '//'. That has some other implications, like that > >> StateNamespaces.fromString(StateNamespaces.window(GlobalWindowCoder, > >> GlobalWindow).stringKey()) != StateNamespaces.global(). > >> > >> It looks like a bug, but maybe I'm wrong - is this intentional? > >> > >> Jan > >> >
