would allow you to manage the intermediate data directly in the state
> instead of the memory
>
>
> -Original Message-
> From: Shaoxuan Wang [mailto:wshaox...@gmail.com]
> Sent: Friday, May 12, 2017 1:20 PM
> To: Dev
> Cc: Stephan Ewen
> Subject: Re: [DISCUSS] Expose State
the intermediate data directly in the state instead of the
memory
-Original Message-
From: Shaoxuan Wang [mailto:wshaox...@gmail.com]
Sent: Friday, May 12, 2017 1:20 PM
To: Dev
Cc: Stephan Ewen
Subject: Re: [DISCUSS] Expose State Backend Interface for UDAGG
Fabian,
Thanks for your quick reply
Fabian,
Thanks for your quick reply.
The goal of "FLINK-6544" is not to expose state backend in all UDAGG cases.
It is designed to provide an interface which provides an ability for user
to access state backend when it is allowed (yes, right now this is only
allowed by ProcessFunction). This
Hi, thanks for the proposal.
I think exposing state to UDAGGs would be very difficult and a lot of work.
UDAGGs are called from ProcessFunctions (stream, OVER window and non-window
aggs), AggregateFunctions (stream, group-window aggs), CombineFunctions
(batch) and GroupReduceFunctions (batch).
Hi everyone,
We made some progress in the implementation of UDAGG (FLINK-5564). However,
we realized that there are cases where users may want to use state backend
to store the data. For instance, the built-in MaxWithRetractAggFunction
currently create a hashMap to store the historical data. It
