I just wanted to add a little bit to my response as I considered the previous FLIP.
I support FLIP-313 and the proposal of the original author. I wasn't trying to take it over, but wanted to show renewed interest. I'm also focused on a smaller MVP, which is why I omitted hint support, which seemed to be a previous point of discussion. This is in line with what I implemented for AsycScalarFunction and has direct parity with the configurations exposed. I just wanted to highlight that difference. Thanks, Alan On Mon, Jan 13, 2025 at 8:55 AM Alan Sheinberg <asheinb...@confluent.io> wrote: > Thanks for the responses Timo, Dawid. > > >> However, why have you decided to resubmit the FLIP with a newer number >> rather than following up on FLIP-313? The only difference I see between >> the >> two FLIPs is the options/hints design. Could you elaborate where the >> differences come from? > > > I think you're right about the hints being the only real difference in > public interface -- I'm not proposing to support them just yet. Since I > was thinking about the implementation details, I wanted to fill some of > those details in more than they were in the previous FLIP. > > Just for my own knowledge, what's the community's policy for addressing > topics covered by previous FLIPs? I figured since it had been 1.5 years > and I had dug into the problem myself, I would create a new one rather than > voice support for the old one. > > Thanks, > Alan > > On Mon, Jan 13, 2025 at 7:25 AM Dawid Wysakowicz <dwysakow...@apache.org> > wrote: > >> Generally what is suggested here makes sense to me. >> >> However, why have you decided to resubmit the FLIP with a newer number >> rather than following up on FLIP-313? The only difference I see between >> the >> two FLIPs is the options/hints design. Could you elaborate where the >> differences come from? >> >> Best, >> Dawid >> >> On Thu, 2 Jan 2025 at 20:48, Alan Sheinberg <asheinb...@confluent.io >> .invalid> >> wrote: >> >> > I'd like to start a discussion of FLIP-498: AsyncTableFunction for async >> > table function support [1] >> > >> > This feature proposes exposing AsyncTableFunction as a proper user >> defined >> > function. The type already exists for Lookup Joins, but isn't usable as >> > other UDFs. This FLIP would bring it up to parity with others. >> > >> > The motivation is similar to other async cases, namely improving >> > performance while issuing long-latency calls to external systems. This >> is >> > similar to AsyncScalarFunction, which exists in Flink. >> > >> > I realize this was effectively proposed in the past in FLIP 313. [2] >> This >> > re-proposes that general feature and gives an update with additional >> > details informed by work on AsyncScalarFunction. >> > >> > Looking forward to your feedback and suggestions. >> > >> > [1] >> > >> > >> https://cwiki.apache.org/confluence/display/FLINK/FLIP-498%3A+AsyncTableFunction+for+async+table+function+support >> > [2] >> > >> > >> https://cwiki.apache.org/confluence/display/FLINK/FLIP-313%3A+Add+support+of+User+Defined+AsyncTableFunction >> > >> > Thanks, >> > Alan >> > >> >
