oh, sorry, I misread. Just my +1 to renaming OperatorState then :-)
On Mon, Dec 14, 2015 at 11:38 AM, Aljoscha Krettek
wrote:
> As I mentioned in my previous mail, I think that OperatorState would need
> be replaced by more specific types of state (ValueState, ListState, …).
>
> > On 14 Dec 2015
+1 to all changes proposed, that is a reasonable step towards incremental
snapshots and proper reconfiguration support. What is more interesting though
is the actual implementations of the KVState derivatives, I am looking forward
to see what you have in mind there. The operator/UDF KV namespace
As I mentioned in my previous mail, I think that OperatorState would need be
replaced by more specific types of state (ValueState, ListState, …).
> On 14 Dec 2015, at 11:34, Maximilian Michels wrote:
>
>>
>> On a side not, why would you call it KvState? And what would be called
>> KvState?
>
>
> On a side not, why would you call it KvState? And what would be called
> KvState?
The OperatorState interface would be called KvState.
On Mon, Dec 14, 2015 at 11:18 AM, Aljoscha Krettek
wrote:
> Yes, as Kostas said, it would initially nor provide more functionality but
> it would enable u
Yes, as Kostas said, it would initially nor provide more functionality but it
would enable us to add it later.
On a side not, why would you call it KvState? And what would be called KvState?
> On 14 Dec 2015, at 11:14, Kostas Tzoumas wrote:
>
> I suppose that they can start as sugar and evolve
I suppose that they can start as sugar and evolve to a different
implementation.
I would +1 the name change to KVState, OperatorState is indeed somewhat
confusing, and it will only get harder to rename later.
On Mon, Dec 14, 2015 at 11:09 AM, Gyula Fóra wrote:
> Would the Reducing/Folding state
Would the Reducing/Folding states just be some API sugar on top of what we
have know (ValueState) or does it have some added functionality (like
incremental checkpoints for list states)?
Gyula
Aljoscha Krettek ezt írta (időpont: 2015. dec. 14.,
H, 11:03):
> While enhancing the state interfaces
While enhancing the state interfaces we would also need to introduce new types
of state. I was thinking of these, for a start:
- ValueState (works like OperatorState works now, i.e. provides methods to
get/set one state value
- ListState, proves methods to add one element to a list of elements
A lot of this makes sense, but I am not sure about renaming
"OperatorState". The other name is nicer, but why make users' life hard
just for a name?
On Mon, Dec 14, 2015 at 10:46 AM, Maximilian Michels wrote:
> Hi Aljoscha,
>
> Thanks for the informative technical description.
>
> > - function
Hi Aljoscha,
Thanks for the informative technical description.
> - function state: this is the state that you get when a user function
> implements the Checkpointed interface. it is not partitioned
> - operator state: This is the state that a StreamOperator can snapshot, it
> is similar to th
Hi All,
I want to discuss some ideas about improving the primitives/operations that
Flink offers for user-state, timers and windows and how these concepts can be
unified.
It has come up a lot lately that people have very specific requirements
regarding the state that they keep and it seems nece
11 matches
Mail list logo
