Re: [DISCUSS] FLIP-309: Enable operators to trigger checkpoints dynamically

2023-06-02 Thread Ahmed Hamdy
Hi Dong, Thanks for the quick reply and for clarification, yeah that makes sense! Best Regards, Ahmed Hamdy On Fri, 2 Jun 2023 at 02:59, Dong Lin wrote: > Hi Ahmed, > > Thanks for the comments. > > I agree with you and Piotr that it would be useful to provide a more > generic approach to address

Re: [DISCUSS] FLIP 295: Support persistence of Catalog configuration and asynchronous registration

2023-06-02 Thread Hang Ruan
Hi, Feng. Thanks for the update. The current design looks good to me. I have some minor comments. 1. The `CatalogStore` need the `open`/`close` methods to init or close the resource. For example, when storing the information in MySQL, the store needs to open and close the connections. 2. The `ge

Re: [DISCUSS] FLIP-316: Introduce SQL Driver

2023-06-02 Thread Paul Lam
Hi Jark, Thanks a lot for your input! > If we decide to submit ExecNodeGraph instead of SQL file, is it still > necessary to support SQL Driver? I think so. Apart from usage in SQL Gateway, SQL Driver could simplify Flink SQL execution with Flink CLI. As the FLIP said, it’s good to have a defa

[jira] [Created] (FLINK-32247) Normal group by with time attributes after a window group by is interpreted as GlobalWindowAggregate

2023-06-02 Thread Qingsheng Ren (Jira)
Qingsheng Ren created FLINK-32247: - Summary: Normal group by with time attributes after a window group by is interpreted as GlobalWindowAggregate Key: FLINK-32247 URL: https://issues.apache.org/jira/browse/FLINK-3

Re: [DISCUSS] FLIP-316: Introduce SQL Driver

2023-06-02 Thread Paul Lam
The FLIP is in the early phase and some details are not included, but fortunately, we got lots of valuable ideas from the discussion. Thanks to everyone who joined the dissuasion! @Weihua @Shanmon @Shengkai @Biao @Jark This weekend I’m gonna revisit and update the FLIP, adding more details. Hope

Re: [DISCUSS] FLIP-313 Add support of User Defined AsyncTableFunction

2023-06-02 Thread Jing Ge
Hi Aitozi, Thanks for the update. Just out of curiosity, what is the difference between the RPC call or query you mentioned and the lookup in a very general way? Since Lateral join is used in the FLIP. Is there any special thought for that? Sorry for asking so many questions. The FLIP contains lim

Re: [DISCUSS] FLIP-307: Flink connector Redshift

2023-06-02 Thread Jing Ge
Hi Samrat, Excited to see your proposal. Supporting data warehouses is one of the major tracks for Flink. Thanks for driving it! Happy to see that we reached consensus to prioritize the Sink over Source in the previous discussion. Do you already have any prototype? I'd like to join the reviews. J

Re: [DISCUSS] FLIP-309: Enable operators to trigger checkpoints dynamically

2023-06-02 Thread Piotr Nowojski
Hi All, Thanks for chipping in the discussion Ahmed! Regarding using the REST API. Currently I'm leaning towards implementing this feature inside the Flink itself, via some pluggable interface. REST API solution would be tempting, but I guess not everyone is using Flink Kubernetes Operator. @Don

Re: [DISCUSS] FLIP-309: Enable operators to trigger checkpoints dynamically

2023-06-02 Thread Dong Lin
Hi Piotr, Thanks for the explanations. I have some followup questions below. On Fri, Jun 2, 2023 at 10:55 PM Piotr Nowojski wrote: > Hi All, > > Thanks for chipping in the discussion Ahmed! > > Regarding using the REST API. Currently I'm leaning towards implementing > this feature inside the Fl

Re: [DISCUSS] FLIP-316: Introduce SQL Driver

2023-06-02 Thread Jark Wu
Hi Paul, Thanks for your reply. I left my comments inline. > As the FLIP said, it’s good to have a default main class for Flink SQLs, > which allows users to submit Flink SQLs in the same way as DataStream > jobs, or else users need to write their own main class. Isn't Table API the same way as

Re: [DISCUSS] FLIP 295: Support persistence of Catalog configuration and asynchronous registration

2023-06-02 Thread Jark Wu
Hi Jing, Thank you for the update. 1. Could you move the CatalogStore registration API to the "Public Interface" section? "Proposed Changes" is more like a place to describe the implementation details. 2. We should prefix "table." for the CatalogStore configuration. Besides, the config key name