Hi Zakelly,
Thanks for your proposal. The FLIP looks in good shape. +1 for it! I'd like
to ask some questions to understand your thoughts more precisely.
1. StateFuture<T> is a new interface. At first glance, it should
be @Experimental. But according to our API Arch rule[1], it should be at
least @PublicEvolving, if it will be used by any existing PublicEvloving
classes. You might want to add this info to your FLIP, if we want to go
with this option.
2. The return types of methods in State and related sub-interfaces are
StateFuture<XXX>. Since the old State interfaces already have those methods
and Java does not allow method overload with the same method but different
return types. Do you want to change the old methods or use new interfaces?
My understanding is that, according to the description in the
"Compatibility, Deprecation, and Migration Plan'' section in the FLIP, new
interfaces will be defined alongside the old interfaces. I guess the
long-term intention of this FLIP is not to deprecate the synchronous State
API. Both State APIs will be supported for different scenarios. In this
case, does it make sense to:
2.1 annotated all new interfaces with @Experimental to have the
flexibility for further modifications?
2.2 use different names e.g. AsyncState etc. to avoid potential
human mistakes while coding(e.g. import wrong package by mistake etc.) and
ease the job development with state?
Best regards,
Jing
[1]
https://github.com/apache/flink/blob/d6a4eb966fbc47277e07b79e7c64939a62eb1d54/flink-architecture-tests/flink-architecture-tests-production/src/main/java/org/apache/flink/architecture/rules/ApiAnnotationRules.java#L99
On Thu, Mar 7, 2024 at 9:49 AM Zakelly Lan <zakelly....@gmail.com> wrote:
> Hi devs,
>
> I'd like to start a discussion on a sub-FLIP of FLIP-423: Disaggregated
> State Storage and Management[1], which is a joint work of Yuan Mei, Zakelly
> Lan, Jinzhong Li, Hangxiang Yu, Yanfei Lei and Feng Wang:
>
> - FLIP-424: Asynchronous State APIs [2]
>
> This FLIP introduces new APIs for asynchronous state access.
>
> Please make sure you have read the FLIP-423[1] to know the whole story, and
> we'll discuss the details of FLIP-424[2] under this mail. For the
> discussion of overall architecture or topics related with multiple
> sub-FLIPs, please post in the previous mail[3].
>
> Looking forward to hearing from you!
>
> [1] https://cwiki.apache.org/confluence/x/R4p3EQ
> [2] https://cwiki.apache.org/confluence/x/SYp3EQ
> [3] https://lists.apache.org/thread/ct8smn6g9y0b8730z7rp9zfpnwmj8vf0
>
>
> Best,
> Zakelly
>
