Thank you for the honest response, Yu! There is so much that comes to mind when we look at Flink as a "application framework" (my talk <https://europe-2019.flink-forward.org/conference-program#not-so-big-%E2%80%93-flink-as-a-true-application-framework> in Flink Forward in Berlin will be about this). QS is one of them (need-wise, not QS itself necessarily). I opened the design doc Vino Yang created, I'll try to contribute to that.
Meanwhile, for the sake of opening our state to outside, we will put a stupid simple operator in between to keep a *duplicate* of the state... Thanks again! --- Oytun Tez *M O T A W O R D* The World's Fastest Human Translation Platform. oy...@motaword.com — www.motaword.com On Tue, Aug 13, 2019 at 6:29 PM Yu Li <car...@gmail.com> wrote: > Hi Oytun, > > Sorry but TBH such support will probably not be added in the foreseeable > future due to lack of committer bandwidth (not only support queryable > broadcast state but all about QueryableState module) as pointed out in > other threads [1] [2]. > > However, I think you could open a JIRA for this so when things changed it > could be taken care of. Thanks. > > [1] https://s.apache.org/MaOl > [2] https://s.apache.org/r8k8a > > Best Regards, > Yu > > > On Tue, 13 Aug 2019 at 20:34, Oytun Tez <oy...@motaword.com> wrote: > >> Hi there, >> >> Can we set a broadcast state as queryable? I've looked around, not much >> to find about it. I am receiving UnknownKvStateLocation when I try to query >> with the descriptor/state name I give to the broadcast state. >> >> If it doesn't work, what could be the alternative? My mind goes around >> ctx.getBroadcastState and making it queryable in the operator level (I'd >> rather not). >> >> --- >> Oytun Tez >> >> *M O T A W O R D* >> The World's Fastest Human Translation Platform. >> oy...@motaword.com — www.motaword.com >> >
