Re: [DISCUSS][2.0] FLIP-344: Remove parameter in RichFunction#open

+1 On Fri, Jul 21, 2023 at 10:22 AM Yuxin Tan wrote: > +1 > > Best, > Yuxin > > > Xintong Song 于2023年7月21日周五 12:04写道： > > > +1 > > > > Best, > > > > Xintong > > > > > > > > On Fri, Jul 21, 2023 at 10:52 AM Wencong Liu > wrote: > > > > > Hi devs, > > > > > > I would like to start a discussion

Re: [DISCUSS][2.0] FLIP-347: Remove IOReadableWritable serialization in Path

Hi Wencong, Just out of curiosity, will the newly introduced deserializeFromDataInputView() method make the Path mutable again? What Matthias suggested makes sense, although the extension might make this FLIP cross multiple modules. Best regards, Jing On Fri, Jul 21, 2023 at 10:23 AM Matthias

Re: [DISCUSS][2.0] FLIP-343: Remove parameter in WindowAssigner#getDefaultTrigger()

+1 NIT: the release in the FLIP is still empty, it should be 2.0 Best regards, Jing On Fri, Jul 21, 2023 at 6:03 AM Xintong Song wrote: > +1 > > Best, > > Xintong > > > > On Fri, Jul 21, 2023 at 10:53 AM Wencong Liu wrote: > > > Hi devs, > > > > I would like to start a discussion on

Re: [DISUCSS] Deprecate multiple APIs in 1.18

this up, Matthias. I've replied to you in the > > other > > > > > thread[1]. > > > > > > > > > > Best, > > > > > > > > > > Xintong > > > > > > > > > > > > > > > [1] > ht

Re: [DISCUSS] Connectors, Formats, and even User Code should also be pluggable.

Hi Zhiqiang, Thanks for your proposal. The idea is very interesting! Since almost all connectors are or will be externalized, the pluggable design you suggested could help reduce the development effort. As you mentioned, the attached doc contains only your preliminary idea. I would suggest that

Re: [DISCUSS] FLIP-346: Deprecate ManagedTable related APIs

+1 On Thu, Jul 20, 2023 at 10:37 AM Lincoln Lee wrote: > +1 > > > Best, > Lincoln Lee > > > Leonard Xu 于2023年7月20日周四 16:26写道： > > > Thanks Jane for driving this FLIP. > > > > > > +1, > > > > Minor: We can remove related document as well, Keeping a external link to > > Apache Paimon should be

Re: [DISCUSS][2.0] FLIP-338: Remove terminationMode query parameter from job cancellation REST endpoint

+1 On Mon, Jul 17, 2023 at 5:30 AM Xintong Song wrote: > +1 > > Best, > > Xintong > > > > On Thu, Jul 13, 2023 at 9:41 PM Chesnay Schepler > wrote: > > > Hello, > > > > The job cancellation REST endpoint has a terminationMode query > > parameter, which in the past could be set to either CANCEL

Re: [DISCUSS][2.0] FLIP-336: Remove "now" timestamp field from REST responses

+1 On Mon, Jul 17, 2023 at 5:29 AM Xintong Song wrote: > +1 > > Best, > > Xintong > > > > On Thu, Jul 13, 2023 at 9:05 PM Chesnay Schepler > wrote: > > > Hello, > > > > Several REST responses contain a timestamp field of the current time > > > > There is no known use-case for said timestamp,

Re: [DISCUSS][2.0] FLIP-341: Remove MetricGroup methods accepting an int as a name

+1 On Tue, Jul 18, 2023 at 1:11 PM Chesnay Schepler wrote: > Good catch; i've fixed the list. > > On 18/07/2023 12:20, Xintong Song wrote: > > +1 in general. > > > > I think the list of affected public interfaces in the FLIP is not > accurate. > > > > - `#counter(int, Counter)` is missed >

Re: FLIP-342: Remove brackets around keys returned by MetricGroup#getAllVariables

+1 On Tue, Jul 18, 2023 at 12:24 PM Xintong Song wrote: > +1 > > Best, > > Xintong > > > > On Tue, Jul 18, 2023 at 5:02 PM Chesnay Schepler > wrote: > > > The FLIP number was changed to 342. > > > > On 18/07/2023 10:56, Chesnay Schepler wrote: > > > MetricGroup#getAllVariables returns all

Re: [DISCUSS][2.0] FLIP-340: Remove rescale REST endpoint

+1 On Tue, Jul 18, 2023 at 1:05 PM Maximilian Michels wrote: > +1 > > On Tue, Jul 18, 2023 at 12:29 PM Gyula Fóra wrote: > > > > +1 > > > > On Tue, 18 Jul 2023 at 12:12, Xintong Song > wrote: > > > > > +1 > > > > > > Best, > > > > > > Xintong > > > > > > > > > > > > On Tue, Jul 18, 2023 at

Re: [DISCUSS][2.0] FLIP-337: Remove JarRequestBody#programArgs

> > > > On 18/07/2023 10:18, Chesnay Schepler wrote: > >> We'll log a warn message when it is used and maybe hide it from the > docs. > >> > >> Archunit rule doesn't really work here because it's not annotated with > stability annotations (as it shouldn'

Re: [VOTE] FLIP-309: Support using larger checkpointing interval when source is processing backlog

+1(binding) Best regards, Jing On Tue, Jul 18, 2023 at 8:31 AM Rui Fan <1996fan...@gmail.com> wrote: > +1(binding) > > Best, > Rui Fan > > > On Tue, Jul 18, 2023 at 12:04 PM Dong Lin wrote: > > > Hi all, > > > > We would like to start the vote for FLIP-309: Support using larger > >

Re: [DISCUSS][2.0] FLIP-337: Remove JarRequestBody#programArgs

Hi Chesnay, I am trying to understand what is the right removal process with this concrete example. Given all things about the programArgs are private or package private except the constructor. Will you just mark it as deprecated with constructor overloading in 1.18 and remove it in 2.0? Should

Re: [DISCUSS] FLIP-330: Support specifying record timestamp requirement

hat's why I chose to > enable object-reuse and to transmit Boolean values in serialization. > If it would be more widely regarded as acceptable for a benchmark to > adopt more commonly-applied behavior(for object reuse, I believe > disable is more common), I would be glad to update the b

Re: [VOTE] Graduate the FileSink to @PublicEvolving

/thread/wxoo7py5pqqlz37l4w8jrq6qdvsdq5wc On Tue, Jul 11, 2023 at 9:56 PM Jing Ge wrote: > Hi, > > Sorry for the typo. The title is correct. The VOTE is for graduating the > "FileSink" to @PublicEvolving. > > Best regards, > Jing > > > On Mon, Jul 10,

Re: [DISCUSS] Deprecating Public API for 2.0 requiring FLIPs

Hi, Thanks Matthias for starting this discussion and thanks Chesnay for the clarification. I don't want to hijack this discussion but I would suggest postponing the 1.18 feature freeze over postponing the deprecations to 1.19. If there are some contributors who think it makes sense, I will raise

Re: [DISCUSS] FLIP-335: Removing Flink's Time classes as part of Flink 2.0

preparing it for 2.0). I created a dedicated discussion thread [1] to > discuss this topic because it's more general and independent of FLIP-335. > > Best, > Matthias > > [1] https://lists.apache.org/thread/1007v4f4ms7ftp1qtkjsq25s5lwmk9wo > > On Thu, Jul 13, 2023 at 12

Re: [DISCUSS] FLIP-335: Removing Flink's Time classes as part of Flink 2.0

Hi Matthias, Thanks for raising this up! I saw your conversation with Chesnay in the PR and after reading the historical discussions, there should be no doubt to deprecate Time classes. +1 I just have a related question: Do we need to create a FLIP each time when we want to deprecate any

Re: [DISCUSS] FLIP-330: Support specifying record timestamp requirement

Hi Yunfeng, Thanks for the proposal. It makes sense to offer the optimization. I got some NIT questions. 1. I guess you changed your thoughts while coding the POC, I found pipeline.enable-operator-timestamp in the code but is pipeline.force-timestamp-support defined in the FLIP 2. about the

Re: [DISCUSS] FLIP-327: Support stream-batch unified operator to improve job throughput when processing backlog data

Hi Dong, Thanks for your reply! Best regards, Jing On Wed, Jul 12, 2023 at 3:25 AM Dong Lin wrote: > Hi Jing, > > Thanks for the comments. Please see my reply inline. > > On Wed, Jul 12, 2023 at 5:04 AM Jing Ge > wrote: > > > Hi Dong, > > > > Thanks

Re: [DISCUSS] FLIP-327: Support stream-batch unified operator to improve job throughput when processing backlog data

by default? Best regards, Jing On Tue, Jul 11, 2023 at 2:58 PM Dong Lin wrote: > Hi Jing, > > Thank you for the comments! Please see my reply inline. > > On Tue, Jul 11, 2023 at 5:41 AM Jing Ge > wrote: > > > Hi Dong, > > > > Thanks for the proposal! The F

Re: [VOTE] Graduate the FileSink to @PublicEvolving

Hi, Sorry for the typo. The title is correct. The VOTE is for graduating the "FileSink" to @PublicEvolving. Best regards, Jing On Mon, Jul 10, 2023 at 1:10 PM Jing Ge wrote: > Hi, > > I'd like to start the VOTE for graduating the FlinkSink > to @PublicEvolving. The

Re: [VOTE] Release 2.0 must-have work items

disaggregated state management". > > > > Since disaggregated state management itself is not a must-have, "Eager > > State Declaration" is not as well. We can downgrade it to "nice to have" > if > > no objection. > > > > Best > >

Re: [VOTE] Release 2.0 must-have work items

gt; contributor > > >> has claimed them yet. I think this is a risk and hope the Release > > Managers > > >> could pay attention to it. > > >> > > >> Thank you all RMs for your work, sorry again for interrupting the vote > > >> &g

Re: [DISCUSS] FLIP 333 - Redesign Apache Flink website

Hi, +1, the UI design looks good! Commonly speaking, there are two parts of the whole website: Flink Web and Flink doc. Will the dart mode also cover Flink doc? Best regards, Jing On Tue, Jul 11, 2023 at 12:40 PM Matthias Pohl wrote: > I also like the proposed designs. Considering that you

Re: [DISCUSS] FLIP-327: Support stream-batch unified operator to improve job throughput when processing backlog data

Hi Dong, Thanks for the proposal! The FLIP is already in good shape. I got some NIT questions. 1. It is a little bit weird to write the hint right after the motivation that some features have been moved to FLIP-331, because at that time, readers don't know the context about what features does it

Re: [DISCUSS] FLIP-325: Support configuring end-to-end allowed latency

Hi Dong, Thanks for the update! Best regards, Jing On Sun, Jul 9, 2023 at 3:26 AM Dong Lin wrote: > Hi Jing, > > Thanks for the suggestions. Please see my reply inline. > > On Fri, Jul 7, 2023 at 3:50 PM Jing Ge wrote: > > > Hi Dong, > > >

[VOTE] Graduate the FileSink to @PublicEvolving

Hi, I'd like to start the VOTE for graduating the FlinkSink to @PublicEvolving. The discussion thread can be found at [1] The vote will be open until at least July 13 12pm GMT(72 hours) unless there is an objection or insufficient votes. Thanks, Jing Ge [1] https://lists.apache.org/thread

Re: [VOTE] Release 2.0 must-have work items

+1 On Mon, Jul 10, 2023 at 12:52 PM Yu Li wrote: > +1 (binding) > > Thanks for driving this and great to see us moving forward. > > Best Regards, > Yu > > > On Mon, 10 Jul 2023 at 11:59, Feng Wang wrote: > > > +1 > > Thanks for driving this, looking forward to the next stage of flink. > > > >

Re: [DISUCSS] Deprecate multiple APIs in 1.18

l 2023 at 10:53, Xintong Song wrote: > > > Thanks all for the discussion. I've created FLINK-32557 for this. > > > > Best, > > > > Xintong > > > > > > > > On Thu, Jul 6, 2023 at 1:00 AM Jing Ge > wrote: > > > > > Hi

Re: [DISCUSS] FLIP-325: Support configuring end-to-end allowed latency

onfigured lower than the checkpoint interval. 3. The three ways you mentioned for how to derive isBacklog. WDYT? Best regards, Jing On Fri, Jul 7, 2023 at 3:13 AM Dong Lin wrote: > Hi Jing, > > Thanks for the comments. Please see my reply inline. > > On Fri, Jul 7, 2023 at 5:40 AM

Re: [DISCUSS] FLIP-314: Support Customized Job Lineage Listener

t consistent > with the job definition in Flink. > > Best, > Shammon FY > > On Thu, Jul 6, 2023 at 8:25 PM Jing Ge wrote: > > > Hi Shammon, > > > > Thanks for the clarification. Atlas might have his historical reason back > > to the hadoop era or maybe even

Re: [DISCUSS] FLIP-325: Support configuring end-to-end allowed latency

Hi, Thank you all for the inspired discussion. Really appreciate it! @Dong I'd like to ask some (stupid) questions to make sure I understand your thoughts correctly. 1. It will make no sense to send the same type of RecordAttributes right? e.g. if one RecordAttributes(isBacklog=true) has been

Re: [DISCUSS] FLIP-314: Support Customized Job Lineage Listener

referred to `Atlas` for the name of lineage, it uses `Entity` and > `Relation` to represent the lineage relationship and another metadata > service `Datahub` uses `DataSet` to represent the entity. I think `Entity` > and `Relation` are nicer for lineage, what do you think of it? > > B

Re: [DISCUSS] FLIP-329: Add operator attribute to specify support for object-reuse

and upgrade to 3VL once there are such real requirements that are rising. Best regards, Jing On Thu, Jul 6, 2023 at 12:30 PM Dong Lin wrote: > Hi Jing, > > Thank you for the detailed explanation. Please see my reply inline. > > On Thu, Jul 6, 2023 at 3:17 AM Jing Ge wrote: > >

Re: [ANNOUNCE] Flink 1.18 Feature Freeze Extended until July 24th, 2023

Thanks for driving it and sharing the update! Best regards, Jing On Thu, Jul 6, 2023 at 9:21 AM yuxia wrote: > Thanks for the update and thanks for your efforts. > > Best regards, > Yuxia > > - 原始邮件 - > 发件人: "Rui Fan" <1996fan...@gmail.com> > 收

Re: [DISCUSS] FLIP-329: Add operator attribute to specify support for object-reuse

On Wed, Jul 5, 2023 at 12:47 PM Dong Lin wrote: > Hi Jing, > > Thanks for the comments! Please find below my comments, which are based on > the offline discussion with Xuannan. > > On Wed, Jul 5, 2023 at 1:36 AM Jing Ge wrote: > >> Hi Xuannan, Hi Dong >> >>

[jira] [Created] (FLINK-32546) update Code Style Guide with Java properties naming convention

Jing Ge created FLINK-32546: --- Summary: update Code Style Guide with Java properties naming convention Key: FLINK-32546 URL: https://issues.apache.org/jira/browse/FLINK-32546 Project: Flink Issue

Re: [DISUCSS] Deprecate multiple APIs in 1.18

gt; > > > > More time is needed for deprecating SinkFunction. > > > > > > I'll leave this discussion open for a few more days. And if there's no > > > objections, I'll create JIRA tickets accordingly. > > > > > > Best, > > > > >

Re: [DISCUSS] FLIP-329: Add operator attribute to specify support for object-reuse

Hi Xuannan, Hi Dong Thanks for the Proposal! After reading the FLIP, I'd like to ask some questions: 1. Naming convention for boolean variables. It is recommended to follow JavaBean [1], i.e. objectReuseCompliant as the variable name with isObjectReuseCompliant() and setObjectReuseCompliant() as

Re: [ANNOUNCE] Apache Flink has won the 2023 SIGMOD Systems Award

Congratulations! Best regards, Jing On Mon, Jul 3, 2023 at 3:21 PM yuxia wrote: > Congratulations! > > Best regards, > Yuxia > > -- > *发件人: *"Pushpa Ramakrishnan" > *收件人: *"Xintong Song" > *抄送: *"dev" , "User" > *发送时间: *星期一, 2023年 7 月 03日 下午 8:36:30 > *主题: *Re:

Re: [DISCUSS] Graduate the FileSink to @PublicEvolving

Hi, If there are no other concerns, I will start voting. Thanks! Best Regards, Jing On Mon, Jun 26, 2023 at 11:35 AM Jing Ge wrote: > Hi, > > @Galen @Yuxia > > Your points are valid. Speaking of removing deprecated API, I have the > same concern. As a matter of fact, I

Re: [DISUCSS] Deprecate multiple APIs in 1.18

Hi Xingtong, Option 1, secure plan would be: 1. graduate kafka, File, JDBC connectors to @Public 2. graduate SinkV2 to @Public 3. remove SinkFunction. Option 2, risky plan but at a fast pace: 1. graduate SinkV2 to @Public and expecting more maintenance effort since there are many known and

Re: [DISCUSS] Release 2.0 Work Items

> Since Immutables implies code generation while java compilation it seems > impossible to use for rules in Scala code. > > On Mon, Jul 3, 2023 at 10:44 AM Jing Ge > wrote: > > > Hi, > > > > Speaking of "Move Calcite rules from Scala to Java", I wa

Re: [VOTE] FLIP-321: introduce an API deprecation process

+1(binding) On Mon, Jul 3, 2023 at 10:19 AM Stefan Richter wrote: > +1 (binding) > > > > On 3. Jul 2023, at 10:08, Martijn Visser > wrote: > > > > +1 (binding) > > > > > > > > On Mon, Jul 3, 2023 at 10:03 AM Xintong Song > wrote: > > > >> +1 (binding) > >> > >>

Re: [DISCUSS] Release 2.0 Work Items

Hi, Speaking of "Move Calcite rules from Scala to Java", I was wondering if this thread is the right place to talk about it. Afaik, the Flink community has decided to abandon Scala. That is the reason, I guess, we want to move those Calcite rules from Scala to Java. On the other side, new Scala

Re: [VOTE] FLIP-309: Support using larger checkpointing interval when source is processing backlog

+1(binding) On Thu, Jun 29, 2023 at 7:47 AM Leonard Xu wrote: > +1 (binding) > > Best, > Leonard > > > On Jun 29, 2023, at 1:25 PM, Jingsong Li wrote: > > > > +1 binding > > > > On Thu, Jun 29, 2023 at 11:03 AM Dong Lin wrote: > >> > >> Hi all, > >> > >> We would like to start the vote for

Re: [DISUCSS] Deprecate multiple APIs in 1.18

Hi Xintong, 2. SourceFunction / SinkFunction This is one with challenges. There were many discussions in the past. 2.1 SourceFunction The voting was passed[1], but there are still some ongoing issues[2]. The SourceFunction is not marked as @deprecated yet[3], afaik. 2.2 SinkFunction SinkV2 is a

Re: [DISCUSS] FLIP-314: Support Customized Job Lineage Listener

Hi Shammon, Thanks for your proposal. After reading the FLIP, I'd like to ask some questions to make sure we are on the same page. Thanks! 1. TableColumnLineageRelation#sinkColumn() should return TableColumnLineageEntity instead of String, right? 2. Since LineageRelation already contains all

Re: [VOTE] FLIP-303: Support REPLACE TABLE AS SELECT statement

+1(binding) On Wed, Jun 28, 2023 at 1:51 PM Mang Zhang wrote: > +1 (no-binding) > > > -- > > Best regards, > Mang Zhang > > > > > > At 2023-06-28 17:48:15, "yuxia" wrote: > >Hi everyone, > >Thanks for all the feedback about FLIP-303: Support REPLACE TABLE AS > SELECT statement[1]. Based on the

Re: [DISCUSS] FLIP-303: Support REPLACE TABLE AS SELECT statement

Hi Yuxia, Thanks for the proposal. Many engines like Snowflake, Databricks support it. +1 "3:Check the atomicity is enabled, it requires both the options table.rtas-ctas.atomicity-enabled is set to true and the corresponding table sink implementation SupportsStaging." Typo? "Option" instead of

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

Hi Paul, Thanks for driving it and thank you all for the informative discussion! The FLIP is in good shape now. As described in the FLIP, SQL Driver will be mainly used to run Flink SQLs in two scenarios: 1. SQL client/gateway in application mode and 2. external system integration. Would you like

Re: [DISCUSS] FLIP-321: Introduce an API deprecation process

e DataStream API throughout 2.X and remove it until 3.x. > > But > > > there's no need to assume that 2.X is a short version, it's still a > > normal > > > major version. > > > > > > Best, > > > Jingsong > > > > > > Becket Qin 于2023年6

Re: [DISCUSS] Graduate the FileSink to @PublicEvolving

hout > incurring the risk of data loss. > > I'm sure I'd feel better about things if there were an ongoing effort to > address this FileSink issue and/or a commitment that StreamingFileSink > would not be removed until this issue is addressed. > > My two cents -- thanks. >

Re: [VOTE] FLIP-324: Introduce Runtime Filter for Flink Batch Jobs

+1(binding) Best Regards, Jing On Fri, Jun 23, 2023 at 5:50 PM Lijie Wang wrote: > Hi all, > > Thanks for all the feedback about the FLIP-324: Introduce Runtime Filter > for Flink Batch Jobs[1]. This FLIP was discussed in [2]. > > I'd like to start a vote for it. The vote will be open for at

Re: [DISCUSS] Graduate the FileSink to @PublicEvolving

sue/FLINK-30238 > > Based on prior discussion, I believe this could lead to data loss with > FileSink. > > > > On Tue, Jun 20, 2023, 5:41 AM Jing Ge wrote: > > > Hi all, > > > > The FileSink has been marked as @Experimental[1] since Oct. 2020. > > Acco

Re: [DISCUSS] FLIP-324: Introduce Runtime Filter for Flink Batch Jobs

ow the simple way, the subsequent gradual optimization. The first > step may be that we can verify the reasonableness of current formula by > TPC-DS case. > > Best, > Ron > > Jing Ge 于2023年6月20日周二 19:46写道： > > > Hi Ron, > > > > Thanks for the clarification. Th

Re: [DISCUSS] FLIP-321: Introduce an API deprecation process

s. I'd > >>>> like > >>>>> to > >>>>>> try giving users more commitments, i.e. the migration period, as > >> long > >>>> as > >>>>> it > >>>>>> does not prevent us from

Re: [DISCUSS] FLIP-324: Introduce Runtime Filter for Flink Batch Jobs

fect anything, and the user is > also likely to change the value of the size. One question, how do you think > we should make it easier for users to control the filter injection？ > > > [1]: > > https://nightlies.apache.org/flink/flink-docs-master/docs/deployment/elastic_scaling/#adapt

[DISCUSS] Graduate the FileSink to @PublicEvolving

Hi all, The FileSink has been marked as @Experimental[1] since Oct. 2020. According to FLIP-197[2], I would like to propose to graduate it to @PublicEvloving in the upcoming 1.18 release. On the other hand, as a related topic, FileSource was marked as @PublicEvolving[3] 3 years ago. It deserves

Re: [DISCUSS] FLIP-324: Introduce Runtime Filter for Flink Batch Jobs

Hi Lijie, Thanks for your proposal. It is a really nice feature. I'd like to ask a few questions to understand your thoughts. Afaiu, the runtime Filter will only be Injected when the gap between the build data size and prob data size is big enough. Let's make an extreme example. If the small

Re: [DISCUSS] FLIP-311: Support Call Stored Procedure

Thanks for your reply. Nice feature! Best regards, Jing On Wed, Jun 14, 2023 at 3:11 AM yuxia wrote: > Yes, you're right. > > Best regards, > Yuxia > > - 原始邮件 ----- > 发件人: "Jing Ge" > 收件人: "dev" > 发送时间: 星期三, 2023年 6 月 14日 上午 4:46:58 &g

Re: [VOTE] FLIP-308: Support Time Travel

+1(binding) On Mon, Jun 19, 2023 at 1:57 PM Benchao Li wrote: > +1 (binding) > > Lincoln Lee 于2023年6月19日周一 19:40写道： > > > +1 (binding) > > > > Best, > > Lincoln Lee > > > > > > yuxia 于2023年6月19日周一 19:30写道： > > > > > +1 (binding) > > > Thanks Feng driving it. > > > > > > Best regards, > > >

Re: [NOTICE] Experimental Java 17 support now available on master

Hi Kurt, Thanks for your contribution. I am a little bit confused about the email title, since your PR[1] is not merged into the master yet. I guess, with "Experimental Java 17 support", you meant it is available on your branch which is based on the master. If I am not mistaken, there is no vote

Re: [DISCUSS] FLIP-321: Introduce an API deprecation process

Hi All, The @Public -> @PublicEvolving proposed by Xintong is a great idea. Especially, after he suggest @PublicRetired, i.e. @PublicEvolving --(2 minor release)--> @Public --> @deprecated --(1 major release)--> @PublicRetired. It will provide a lot of flexibility without breaking any rules we

Re: [DISCUSS] FLIP-321: Introduce an API deprecation process

rds > incompatible change in the connectors due to a backwards incompatible > change in the core, and as a result a longer migration period is required, > then I think we should postpone the removal of source code. But in general, > we should be able to provide the same migration period

Re: [VOTE] FLIP-287: Extend Sink#InitContext to expose TypeSerializer, ObjectReuse and JobID

+1(binding) Best Regards, Jing On Fri, Jun 16, 2023 at 10:10 AM Lijie Wang wrote: > +1 (binding) > > Thanks for driving it, Joao. > > Best, > Lijie > > Joao Boto 于2023年6月16日周五 15:53写道： > > > Hi all, > > > > Thank you to everyone for the feedback on FLIP-287[1]. Based on the > > discussion

Re: [VOTE] FLIP-246: Dynamic Kafka Source (originally Multi Cluster Kafka Source)

+1 (binding) Best regards, Jing On Thu, Jun 15, 2023 at 7:55 PM Mason Chen wrote: > Hi all, > > Thank you to everyone for the feedback on FLIP-246 [1]. Based on the > discussion thread [2], we have come to a consensus on the design and are > ready to take a vote to contribute this to Flink. >

Re: [VOTE] FLIP-295: Support lazy initialization of catalogs and persistence of catalog configurations

+1 (binding) Best Regards, Jing On Wed, Jun 14, 2023 at 3:28 PM Rui Fan <1996fan...@gmail.com> wrote: > +1(binding) > > Best, > Rui Fan > > On Wed, Jun 14, 2023 at 16:24 Hang Ruan wrote: > > > +1 (non-binding) > > > > Thanks for Feng driving it. > > > > Best, > > Hang > > > > Feng Jin

Re: [VOTE] FLIP-294: Support Customized Catalog Modification Listener

+1 (binding) Best Regards, Jing On Wed, Jun 14, 2023 at 4:07 PM Benchao Li wrote: > +1 (binding) > > Shammon FY 于2023年6月14日周三 19:52写道： > > > Hi all: > > > > Thanks for all the feedback for FLIP-294: Support Customized Catalog > > Modification Listener [1]. I would like to start a vote for it

Re: Re: [VOTE] FLIP-311: Support Call Stored Procedure

+1(binding) Best Regards, Jing On Tue, Jun 13, 2023 at 9:03 AM Mang Zhang wrote: > +1 (no-binding) > > > > > -- > > Best regards, > Mang Zhang > > > > > > 在 2023-06-13 13:19:31，"Lincoln Lee" 写道： > >+1 (binding) > > > >Best, > >Lincoln Lee > > > > > >Jingsong Li 于2023年6月13日周二 10:07写道： > > >

Re: [DISCUSS] FLIP-311: Support Call Stored Procedure

Hi yuxia, Thanks for your proposal and sorry for the late reply. The FLIP is in good shape. If I am not mistaken, Everything, that a stored procedure could do, could also be done by a Flink job. The current stored procedure design is to empower Catalogs to provide users some commonly used

Re: [DISCUSS] FLIP-321: Introduce an API deprecation process

2023 at 4:25 PM Chesnay Schepler wrote: > On 13/06/2023 12:50, Jing Ge wrote: > > One major issue we have, afaiu, is caused by the lack of > housekeeping/house > > cleaning, there are many APIs that were marked as deprecated a few years > > ago and still don't get removed

Re: [DISCUSS] FLIP-321: Introduce an API deprecation process

Hi Becket, Thanks for driving this important topic! There were many discussions previously that ended up with waiting up for a clear API deprecation process definition. This FLIP will help a lot. I'd like to ask some questions to understand your thoughts. Speaking of the FLIP, *"Always add a

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

ion > > should be a point to be taken care about. Because in the ordered mode, > the > > head element in buffer may affect the > > total memory consumption. > > > > > > Thanks, > > Aitozi. > > > > > > > > Jing Ge 于2023年6月12日周一 20:28写道： &g

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

ink > that's why the > LookupFunction#lookup will return a collection of RowData. > > BTW, I think the behavior of lookup join will not affect the semantic of > the async udtf. > We use the Async TableFunction here and the table function can collect > multiple rows. > > Thanks, >

Re: [VOTE] FLIP-305: Support atomic for CREATE TABLE AS SELECT(CTAS) statement

+1(binding) Thanks! Best regards, Jing On Mon, Jun 12, 2023 at 12:01 PM yuxia wrote: > +1 (binding) > Thanks Mang driving it. > > Best regards, > Yuxia > > - 原始邮件 - > 发件人: "zhangmang1" > 收件人: "dev" > 发送时间: 星期一, 2023年 6 月 12日 下午 5:31:10 > 主题: [VOTE] FLIP-305: Support atomic for CREATE

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

xperiences would be immensely valuable in making this > > decision. > > > > > > [1] > > > https://docs.aws.amazon.com/redshift/latest/dg/t_updating-inserting-using-staging-tables-.html > > [2] https://docs.aws.amazon.com/redshift/latest/dg/merge-examples.

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

ction of > joined result, and each of them will be collected > > > [1]: > > https://github.com/apache/flink/blob/191ec6ca3943d7119f14837efe112e074d815c47/flink-table/flink-table-common/src/main/java/org/apache/flink/table/functions/LookupFunction.java#L52 > > > Thanks, &g

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

hese option, I updated the FLIP about this you can > refer to > the section of "ConfigOption" and "Rejected Alternatives" > > In the end, for the performance evaluation, I'd like to do some tests and > will update it to the FLIP doc > > Thanks, > Aitozi. > &g

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

s://nightlies.apache.org/flink/flink-docs-release-1.17/docs/dev/table/sql/queries/joins/#lookup-join > > > >.You > > > > can image the look up process as an async RPC call process. > > > > > > > > Let's see how we can perform an async R

Call for Presentations: Flink Forward Seattle 2023

ward to receiving your submission and welcoming you as a speaker at the Flink Forward Conference. Thank you for your time and consideration. Best regards, -- Jing Ge | Head of Engineering j...@ververica.com <https://www.ververica.com/> Follow us @VervericaData -- Join Flink Forw

Re: [DISCUSS] FLIP-315: Support Operator Fusion Codegen for Flink SQL

pic and observation > > > > For the performance benchmark, I agree with you. As I stated earlier, I > > think this is a new scope of work, we should design it separately, we can > > introduce this improvement in the future. > > > > [1] > > > https://github.com

Re: [DISCUSS] FLIP-294: Support Customized Job Meta Data Listener

://www.java2s.com/example/java-src/pkg/java/util/eventobject-85298.html On Thu, Jun 8, 2023 at 7:50 AM Shammon FY wrote: > Hi, > > To @Jing Ge > > Thanks for the clarification. Just out of curiosity, if the context is > not part of the event, why should it be the input parameter of each onE

Re: [VOTE] FLIP-315: Support Operator Fusion Codegen for Flink SQL

+1 Best Regards, Jing On Wed, Jun 7, 2023 at 10:52 AM weijie guo wrote: > +1 (binding) > > Best regards, > > Weijie > > > Jingsong Li 于2023年6月7日周三 15:59写道： > > > +1 > > > > On Wed, Jun 7, 2023 at 3:03 PM Benchao Li wrote: > > > > > > +1, binding > > > > > > Jark Wu 于2023年6月7日周三 14:44写道： > >

Re: [DISCUSS] FLIP-315: Support Operator Fusion Codegen for Flink SQL

Hi Ron, Thanks for raising the proposal. It is a very attractive idea! Since the FLIP is a relatively complex one which contains three papers and a design doc. It deserves more time for the discussion to make sure everyone is on the same page. I have a NIT question which will not block your

Re: [DISCUSS] FLIP-246: Multi Cluster Kafka Source

Hi Mason, It is a very practical feature that many users are keen to use. Thanks to the previous discussion, the FLIP now looks informative. Thanks for your proposal. One small suggestion is that the attached images are quite small to read if we don't click and enlarge them. Besides that, It is

Re: [DISCUSS] FLIP-294: Support Customized Job Meta Data Listener

LIP looks good to me. > > Hope to see the vote thread and following FLIP-314 discussion thread. > > Best, > Leonard > > > On Jun 6, 2023, at 5:04 PM, Shammon FY wrote: > > > > Hi, > > > > Thanks for all the feedback. > > > > For @Jing G

Re: [DISCUSS] FLIP-294: Support Customized Job Meta Data Listener

Hi Shammon, Thanks for driving it! It is a really interesting proposal. Looking forward to the follow-up FLIP for the lineage feature, users will love it :-) There are some inconsistencies in the content. In the very below example, listener.onEvent(CatalogModificationEvent) is called, while in

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

Hi Samrat, Thanks for the feedback. I would suggest adding that information into the FLIP. +1 Looking forward to your PR :-) Best regards, Jing On Sat, Jun 3, 2023 at 9:19 PM Samrat Deb wrote: > Hi Jing Ge, > > >>> Do you already have any prototype? I'd like t

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

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.

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

> users have > logic to do some RPC call or query the third-party service which is also IO > intensive. > In these case, we'd like to leverage the async function to improve the > throughput. > > Thanks, > Aitozi. > > Jing Ge 于2023年6月1日周四 22:55写道： > > > Hi Aitoz

Re: [DISCUSS] Update Flink Roadmap

updated version of the > current roadmap. > Let's work together on refining the roadmap in this thread. > > Best, > Jark > > On Thu, 1 Jun 2023 at 23:25, Jing Ge wrote: > > > Hi Jark, > > > > Thanks for driving it! For point 2, since we are developi

Re: [DISCUSS] Update Flink Roadmap

Hi Jark, Thanks for driving it! For point 2, since we are developing 1.18 now, does it make sense to update the roadmap this time while we are releasing 1.18? This discussion thread will be focusing on the Flink 2.0 roadmap, as you mentioned previously. WDYT? Best regards, Jing On Thu, Jun 1,

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

to a > > CommonExecCorrelate node. So the runtime code should be generated in > > CorrelatedCodeGenerator. > > In CorrelatedCodeGenerator, we will know the TableFunction's Kind of > > `FunctionKind.Table` or `FunctionKind.ASYNC_TABLE` > > For `FunctionKind.A

Re: [VOTE] Release flink-connector-pulsar 3.0.1, release candidate #1

+1(non-binding) - verified sign - verified hash - checked repos - checked tag. NIT: the tag link should be: https://github.com/apache/flink-connector-pulsar/releases/tag/v3.0.1-rc1 - reviewed PR. NIT: left a comment. Best regards, Jing On Wed, May 31, 2023 at 11:16 PM Neng Lu wrote: > +1 > >

Re: [DISCUSS] FLIP-308: Support Time Travel In Batch Mode

Hi Feng, Thanks for the proposal! Very interesting feature. Would you like to update your thoughts described in your previous email about why SupportsTimeTravel has been rejected into the FLIP? This will help readers understand the context (in the future). Since we always directly add overload

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

> sources > b) if there is no backpressure, that's the only case where the user > actually cares about the frequency of committing records to the output, we > are > using the more frequent checkpointing interval. > > 1b) I think is mostly harmless, and I think could

Re: [SUMMARY] Flink 1.18 Release Sync 05/30/2023

Thanks Qingsheng for driving it! @Devs As you might already be aware of, there are many externalizations and new releases of Flink connectors. Once a connector has been externalized successfully, i.e. the related module has been removed in the Flink repo, we will not set a priority higher than

<    1   2   3   4   5   6   7   8   >