Hi Zakelly, Thanks for your clarification! I would suggest explicitly adding description(better highlight) into the FLIP that the original State API will be deprecated. My gut feeling is that it is very important for anyone, who will review the new design, to understand the long-term intention.
Best regards, Jing On Mon, Mar 11, 2024 at 8:01 AM Zakelly Lan <zakelly....@gmail.com> wrote: > Hi Jing, > > Thanks for your comments! > > Sorry for not making this clear. Actually these APIs are in some newly > introduced classes, which are located in a different package name with the > original ones. I suggest we name it "State API V2" and the package name > will be 'org.apache.flink.api.common.state.v2'. They work closely with the > Datastream V2 and are annotated with @Experimental in first few versions, > and will be promoted to @PublicEvolving alongside the DataStream V2. I > agree that the name of interfaces should add 'async', and we will also > support synchronous APIs in these new API classes. This approach allows us > to: > > 1. Have enough flexibility for rapid development with @Experimental > annotation. > 2. Provide both sync and async style APIs for greater ease of use. > 3. Release ourselves from legacy constraints that prevent altering > interface signatures, and we can do something like reorganizing the > exceptions as FLIP-368[1] proposed. > > State API V2 will become the exclusive API set available to users when > working with DataStream API V2. We may discuss the deprecation of original > ones in future. > > WDYT? > > > Best, > Zakelly > > > On Sun, Mar 10, 2024 at 8:34 PM Jing Ge <j...@ververica.com.invalid> > wrote: > >> 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 >> > >> >
