Hi Kenn,
cool, thanks for explanation. The name is maybe a little misleading
then, because the model uses word "global" for global-windowed scope,
but that is absolutely minor issue.
Jan
On 8/16/19 10:57 PM, Kenneth Knowles wrote:
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
<mailto: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
>>
