[jira] [Created] (FLINK-33267) Support PreparedStatement in JDBC Driver

[Dan Zou (Jira)]

Dan Zou created FLINK-33267:
---

 Summary: Support PreparedStatement in JDBC Driver
 Key: FLINK-33267
 URL: https://issues.apache.org/jira/browse/FLINK-33267
 Project: Flink
  Issue Type: New Feature
Reporter: Dan Zou


A PreparedStatement is used to execute parameterized SQL queries. It would be 
helpful to implement PreparedStatement in JDBC Driver.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (FLINK-33266) Support plan cache for SQL jobs

[Dan Zou (Jira)]

Dan Zou created FLINK-33266:
---

 Summary: Support plan cache for SQL jobs
 Key: FLINK-33266
 URL: https://issues.apache.org/jira/browse/FLINK-33266
 Project: Flink
  Issue Type: Sub-task
Reporter: Dan Zou


In OLAP scenarios, running a single query typically cost hundreds of 
milliseconds or a few seconds, of which it takes about tens of milliseconds to 
parse, validate, optimize, and translate it to Flink transformations. Adding 
cache to cache the transformations corresponding to queries is meaningful for 
scenarios where certain queries are often executed repeatedly.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [VOTE] FLIP-366: Support standard YAML for FLINK configuration

[Yuxin Tan]

+1(non-binding)

Best,
Yuxin


Zhanghao Chen  于2023年10月13日周五 10:54写道：

> +1 (non-binding)
>
> Best,
> Zhanghao Chen
> 
> From: Junrui Lee 
> Sent: Friday, October 13, 2023 10:12
> To: dev@flink.apache.org 
> Subject: [VOTE] FLIP-366: Support standard YAML for FLINK configuration
>
> Hi all,
>
> Thank you to everyone for the feedback on FLIP-366[1]: Support standard
> YAML for FLINK configuration in the discussion thread [2].
> I would like to start a vote for it. The vote will be open for at least 72
> hours (excluding weekends, unless there is an objection or an insufficient
> number of votes).
>
> Thanks,
> Junrui
>
> [1]
>
> https://cwiki.apache.org/confluence/display/FLINK/FLIP-366%3A+Support+standard+YAML+for+FLINK+configuration
> [2]https://lists.apache.org/thread/qfhcm7h8r5xkv38rtxwkghkrcxg0q7k5
>

Re: [VOTE] FLIP-366: Support standard YAML for FLINK configuration

[Lijie Wang]

+1 (binding)

Best,
Lijie

Zhanghao Chen  于2023年10月13日周五 10:56写道：

> +1 (non-binding)
>
> Best,
> Zhanghao Chen
> 
> From: Junrui Lee 
> Sent: Friday, October 13, 2023 10:12
> To: dev@flink.apache.org 
> Subject: [VOTE] FLIP-366: Support standard YAML for FLINK configuration
>
> Hi all,
>
> Thank you to everyone for the feedback on FLIP-366[1]: Support standard
> YAML for FLINK configuration in the discussion thread [2].
> I would like to start a vote for it. The vote will be open for at least 72
> hours (excluding weekends, unless there is an objection or an insufficient
> number of votes).
>
> Thanks,
> Junrui
>
> [1]
>
> https://cwiki.apache.org/confluence/display/FLINK/FLIP-366%3A+Support+standard+YAML+for+FLINK+configuration
> [2]https://lists.apache.org/thread/qfhcm7h8r5xkv38rtxwkghkrcxg0q7k5
>

Re: [VOTE] FLIP-366: Support standard YAML for FLINK configuration

[Zhanghao Chen]

+1 (non-binding)

Best,
Zhanghao Chen

From: Junrui Lee 
Sent: Friday, October 13, 2023 10:12
To: dev@flink.apache.org 
Subject: [VOTE] FLIP-366: Support standard YAML for FLINK configuration

Hi all,

Thank you to everyone for the feedback on FLIP-366[1]: Support standard
YAML for FLINK configuration in the discussion thread [2].
I would like to start a vote for it. The vote will be open for at least 72
hours (excluding weekends, unless there is an objection or an insufficient
number of votes).

Thanks,
Junrui

[1]
https://cwiki.apache.org/confluence/display/FLINK/FLIP-366%3A+Support+standard+YAML+for+FLINK+configuration
[2]https://lists.apache.org/thread/qfhcm7h8r5xkv38rtxwkghkrcxg0q7k5

Re: [VOTE] FLIP-366: Support standard YAML for FLINK configuration

[Yangze Guo]

+1 (binding)

Best,
Yangze Guo

On Fri, Oct 13, 2023 at 10:38 AM Yuepeng Pan  wrote:
>
> +1(non-binding)
>
> Best,
> Yuepeng Pan
> At 2023-10-13 10:24:15, "Wencong Liu"  wrote:
> >+1(non-binding)
> >
> >Best,
> >Wencong Liu
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >At 2023-10-13 10:12:06, "Junrui Lee"  wrote:
> >>Hi all,
> >>
> >>Thank you to everyone for the feedback on FLIP-366[1]: Support standard
> >>YAML for FLINK configuration in the discussion thread [2].
> >>I would like to start a vote for it. The vote will be open for at least 72
> >>hours (excluding weekends, unless there is an objection or an insufficient
> >>number of votes).
> >>
> >>Thanks,
> >>Junrui
> >>
> >>[1]
> >>https://cwiki.apache.org/confluence/display/FLINK/FLIP-366%3A+Support+standard+YAML+for+FLINK+configuration
> >>[2]https://lists.apache.org/thread/qfhcm7h8r5xkv38rtxwkghkrcxg0q7k5

[jira] [Created] (FLINK-33265) Support source parallelism setting for Kafka connector

[Zhanghao Chen (Jira)]

Zhanghao Chen created FLINK-33265:
-

 Summary: Support source parallelism setting for Kafka connector
 Key: FLINK-33265
 URL: https://issues.apache.org/jira/browse/FLINK-33265
 Project: Flink
  Issue Type: Sub-task
  Components: Connectors / Kafka
Reporter: Zhanghao Chen






--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (FLINK-33264) Support source parallelism setting for DataGen connector

[Zhanghao Chen (Jira)]

Zhanghao Chen created FLINK-33264:
-

 Summary: Support source parallelism setting for DataGen connector
 Key: FLINK-33264
 URL: https://issues.apache.org/jira/browse/FLINK-33264
 Project: Flink
  Issue Type: Sub-task
Reporter: Zhanghao Chen






--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re:[VOTE] FLIP-366: Support standard YAML for FLINK configuration

[Yuepeng Pan]

+1(non-binding)

Best,
Yuepeng Pan
At 2023-10-13 10:24:15, "Wencong Liu"  wrote:
>+1(non-binding)
>
>Best,
>Wencong Liu
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>At 2023-10-13 10:12:06, "Junrui Lee"  wrote:
>>Hi all,
>>
>>Thank you to everyone for the feedback on FLIP-366[1]: Support standard
>>YAML for FLINK configuration in the discussion thread [2].
>>I would like to start a vote for it. The vote will be open for at least 72
>>hours (excluding weekends, unless there is an objection or an insufficient
>>number of votes).
>>
>>Thanks,
>>Junrui
>>
>>[1]
>>https://cwiki.apache.org/confluence/display/FLINK/FLIP-366%3A+Support+standard+YAML+for+FLINK+configuration
>>[2]https://lists.apache.org/thread/qfhcm7h8r5xkv38rtxwkghkrcxg0q7k5

[jira] [Created] (FLINK-33263) Implement ParallelismProvider for sources in Blink planner

[Zhanghao Chen (Jira)]

Zhanghao Chen created FLINK-33263:
-

 Summary: Implement ParallelismProvider for sources in Blink planner
 Key: FLINK-33263
 URL: https://issues.apache.org/jira/browse/FLINK-33263
 Project: Flink
  Issue Type: Sub-task
  Components: Table SQL / Planner
Reporter: Zhanghao Chen






--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (FLINK-33262) Extend source provider interfaces with the new parallelism provider interface

[Zhanghao Chen (Jira)]

Zhanghao Chen created FLINK-33262:
-

 Summary: Extend source provider interfaces with the new 
parallelism provider interface
 Key: FLINK-33262
 URL: https://issues.apache.org/jira/browse/FLINK-33262
 Project: Flink
  Issue Type: Sub-task
  Components: Table SQL / API
Reporter: Zhanghao Chen






--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re:[VOTE] FLIP-366: Support standard YAML for FLINK configuration

[Wencong Liu]

+1(non-binding)

Best,
Wencong Liu















At 2023-10-13 10:12:06, "Junrui Lee"  wrote:
>Hi all,
>
>Thank you to everyone for the feedback on FLIP-366[1]: Support standard
>YAML for FLINK configuration in the discussion thread [2].
>I would like to start a vote for it. The vote will be open for at least 72
>hours (excluding weekends, unless there is an objection or an insufficient
>number of votes).
>
>Thanks,
>Junrui
>
>[1]
>https://cwiki.apache.org/confluence/display/FLINK/FLIP-366%3A+Support+standard+YAML+for+FLINK+configuration
>[2]https://lists.apache.org/thread/qfhcm7h8r5xkv38rtxwkghkrcxg0q7k5

Re: [VOTE] FLIP-366: Support standard YAML for FLINK configuration

[weijie guo]

+1(binding)

Best regards,

Weijie


Samrat Deb  于2023年10月13日周五 10:21写道：

> +1 (non binding )
>
> On Fri, 13 Oct 2023 at 7:47 AM, Rui Fan <1996fan...@gmail.com> wrote:
>
> > +1(binding)
> >
> > Best,
> > Rui Fan
> >
> > On Fri, Oct 13, 2023 at 10:12 AM Junrui Lee  wrote:
> >
> > > Hi all,
> > >
> > > Thank you to everyone for the feedback on FLIP-366[1]: Support standard
> > > YAML for FLINK configuration in the discussion thread [2].
> > > I would like to start a vote for it. The vote will be open for at least
> > 72
> > > hours (excluding weekends, unless there is an objection or an
> > insufficient
> > > number of votes).
> > >
> > > Thanks,
> > > Junrui
> > >
> > > [1]
> > >
> > >
> >
> https://cwiki.apache.org/confluence/display/FLINK/FLIP-366%3A+Support+standard+YAML+for+FLINK+configuration
> > > [2]https://lists.apache.org/thread/qfhcm7h8r5xkv38rtxwkghkrcxg0q7k5
> > >
> >
>

[jira] [Created] (FLINK-33261) FLIP-367: Support Setting Parallelism for Table/SQL Sources

[Zhanghao Chen (Jira)]

Zhanghao Chen created FLINK-33261:
-

 Summary: FLIP-367: Support Setting Parallelism for Table/SQL 
Sources
 Key: FLINK-33261
 URL: https://issues.apache.org/jira/browse/FLINK-33261
 Project: Flink
  Issue Type: New Feature
  Components: Table SQL / API
Reporter: Zhanghao Chen


Umbrella issue for [FLIP-367: Support Setting Parallelism for Table/SQL Sources 
- Apache Flink - Apache Software 
Foundation|https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=263429150].



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [VOTE] FLIP-366: Support standard YAML for FLINK configuration

[Samrat Deb]

+1 (non binding )

On Fri, 13 Oct 2023 at 7:47 AM, Rui Fan <1996fan...@gmail.com> wrote:

> +1(binding)
>
> Best,
> Rui Fan
>
> On Fri, Oct 13, 2023 at 10:12 AM Junrui Lee  wrote:
>
> > Hi all,
> >
> > Thank you to everyone for the feedback on FLIP-366[1]: Support standard
> > YAML for FLINK configuration in the discussion thread [2].
> > I would like to start a vote for it. The vote will be open for at least
> 72
> > hours (excluding weekends, unless there is an objection or an
> insufficient
> > number of votes).
> >
> > Thanks,
> > Junrui
> >
> > [1]
> >
> >
> https://cwiki.apache.org/confluence/display/FLINK/FLIP-366%3A+Support+standard+YAML+for+FLINK+configuration
> > [2]https://lists.apache.org/thread/qfhcm7h8r5xkv38rtxwkghkrcxg0q7k5
> >
>

[RESULT][VOTE] FLIP-367: Support Setting Parallelism for Table/SQL Sources

[Zhanghao Chen]

Hi devs,

Thanks everyone for your review and the votes!

I am happy to announce that FLIP-367: Support Setting Parallelism for Table/SQL 
Sources [1] has been accepted.

There are 10 binding votes and 5 non-binding votes [2]:
- Benchao Li (binding)
- Shammon FY (binding)
- Weihua Hu (binding)
- Yun Tang (binding)
- Yangze Guo (binding)
- Feng Jing
- xiangyu feng
- Ahmed Hamd
- Jing Ge (binding)
- Leonard Xu (binding)
- Lincoln Lee (binding)
- Sergey Nuyanzin (binding)
- Martijn Visser (binding)
- Samrat Deb
- Jane Chan

There is no disapproving vote.

[1] https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=263429150
[2] https://lists.apache.org/thread/bzlcw28jn0xx1hh45q0ry8wnxf0xoptg

Best,
Zhanghao Chen

Re: [VOTE] FLIP-366: Support standard YAML for FLINK configuration

[Rui Fan]

+1(binding)

Best,
Rui Fan

On Fri, Oct 13, 2023 at 10:12 AM Junrui Lee  wrote:

> Hi all,
>
> Thank you to everyone for the feedback on FLIP-366[1]: Support standard
> YAML for FLINK configuration in the discussion thread [2].
> I would like to start a vote for it. The vote will be open for at least 72
> hours (excluding weekends, unless there is an objection or an insufficient
> number of votes).
>
> Thanks,
> Junrui
>
> [1]
>
> https://cwiki.apache.org/confluence/display/FLINK/FLIP-366%3A+Support+standard+YAML+for+FLINK+configuration
> [2]https://lists.apache.org/thread/qfhcm7h8r5xkv38rtxwkghkrcxg0q7k5
>

[VOTE] FLIP-366: Support standard YAML for FLINK configuration

[Junrui Lee]

Hi all,

Thank you to everyone for the feedback on FLIP-366[1]: Support standard
YAML for FLINK configuration in the discussion thread [2].
I would like to start a vote for it. The vote will be open for at least 72
hours (excluding weekends, unless there is an objection or an insufficient
number of votes).

Thanks,
Junrui

[1]
https://cwiki.apache.org/confluence/display/FLINK/FLIP-366%3A+Support+standard+YAML+for+FLINK+configuration
[2]https://lists.apache.org/thread/qfhcm7h8r5xkv38rtxwkghkrcxg0q7k5

[jira] [Created] (FLINK-33260) Custom Error Handling for Kinesis Consumer

[Danny Cranmer (Jira)]

Danny Cranmer created FLINK-33260:
-

 Summary: Custom Error Handling for Kinesis Consumer
 Key: FLINK-33260
 URL: https://issues.apache.org/jira/browse/FLINK-33260
 Project: Flink
  Issue Type: Improvement
  Components: Connectors / Kinesis
Reporter: Danny Cranmer


Background

The Kinesis Consumer exposes various configuration that allows the user to 
define retry and backoff strategies when dealing with errors. However, the 
configuration does not allow the user to configure which errors are retryable, 
or different strategies for different errors. The error handling logic is hard 
coded within the connector. Over time we discover errors that should be 
retryable that are not, for example KDS throwing 500 on SubscribeToShare or 
transient DNS issues. 
h3. Scope

Add the ability for the user to define retry/backoff strategy per error. This 
could be achieved using flexible configuration keys, or allowing the user to 
register their own retry strategies on the connector

 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (FLINK-33259) flink-connector-aws should use/extend the common connector workflow

[Hong Liang Teoh (Jira)]

Hong Liang Teoh created FLINK-33259:
---

 Summary: flink-connector-aws should use/extend the common 
connector workflow
 Key: FLINK-33259
 URL: https://issues.apache.org/jira/browse/FLINK-33259
 Project: Flink
  Issue Type: Technical Debt
Reporter: Hong Liang Teoh


We should use the common ci github workflow.
[https://github.com/apache/flink-connector-shared-utils/blob/ci_utils/.github/workflows/ci.yml]

 

Example used in flink-connector-elasticsearch

[https://github.com/apache/flink-connector-elasticsearch/blob/main/.github/workflows/push_pr.yml]

 

This improves our operational stance because we will now inherit any 
improvements/changes to the main ci workflow file



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [VOTE] FLIP-371: Provide initialization context for Committer creation in TwoPhaseCommittingSink

[Márton Balassi]

+1 (binding)

Marton

On Wed, Oct 11, 2023 at 8:20 PM Gyula Fóra  wrote:

> Thanks , Peter.
>
> +1
>
> Gyula
>
> On Wed, 11 Oct 2023 at 14:47, Péter Váry 
> wrote:
>
> > Hi all,
> >
> > Thank you to everyone for the feedback on FLIP-371[1].
> > Based on the discussion thread [2], I think we are ready to take a vote
> to
> > contribute this to Flink.
> > I'd like to start a vote for it.
> > The vote will be open for at least 72 hours (excluding weekends, unless
> > there is an objection or an insufficient number of votes).
> >
> > Thanks,
> > Peter
> >
> >
> > [1]
> >
> >
> https://cwiki.apache.org/confluence/display/FLINK/FLIP-371%3A+Provide+initialization+context+for+Committer+creation+in+TwoPhaseCommittingSink
> > [2] https://lists.apache.org/thread/v3mrspdlrqrzvbwm0lcgr0j4v03dx97c
> >
>

[jira] [Created] (FLINK-33258) Remove Kafka/Gelly module

[Matthias Pohl (Jira)]

Matthias Pohl created FLINK-33258:
-

 Summary: Remove Kafka/Gelly module
 Key: FLINK-33258
 URL: https://issues.apache.org/jira/browse/FLINK-33258
 Project: Flink
  Issue Type: Sub-task
Reporter: Matthias Pohl






--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [VOTE] FLIP-239: Port JDBC Connector to FLIP-27-143

[Leonard Xu]

Thanks Joao for driving this work.

+1 (binding)

Best,
Leonard

> On Oct 12, 2023, at 7:09 PM, Sergey Nuyanzin  wrote:
> 
> +1 (binding)

[jira] [Created] (FLINK-33257) Support filter pushdown in MongoDB connector

[Jiabao Sun (Jira)]

Jiabao Sun created FLINK-33257:
--

 Summary: Support filter pushdown in MongoDB connector
 Key: FLINK-33257
 URL: https://issues.apache.org/jira/browse/FLINK-33257
 Project: Flink
  Issue Type: Improvement
  Components: Connectors / MongoDB
Reporter: Jiabao Sun


Support filter pushdown in MongoDB connector



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (FLINK-33256) Fatal error due to dubious ownership in docs-404-check

[Matthias Pohl (Jira)]

Matthias Pohl created FLINK-33256:
-

 Summary: Fatal error due to dubious ownership in docs-404-check
 Key: FLINK-33256
 URL: https://issues.apache.org/jira/browse/FLINK-33256
 Project: Flink
  Issue Type: Sub-task
Reporter: Matthias Pohl


https://github.com/XComp/flink/actions/runs/6468655160/job/17561122928#step:5:5

{code}
fatal: detected dubious ownership in repository at '/__w/flink/flink'
{code}

This doesn't seem to be an issue in other checkouts (e.g. [compile in the same 
build|https://github.com/XComp/flink/actions/runs/6468655160/job/17561123488#step:5:30]
 where the directory is added as safe directory temporarily).



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (FLINK-33255) Validate argument count during type inference

[Dawid Wysakowicz (Jira)]

Dawid Wysakowicz created FLINK-33255:


 Summary: Validate argument count during type inference
 Key: FLINK-33255
 URL: https://issues.apache.org/jira/browse/FLINK-33255
 Project: Flink
  Issue Type: Bug
  Components: Table SQL / Planner
Reporter: Dawid Wysakowicz
Assignee: Dawid Wysakowicz
 Fix For: 1.19.0


Currently we do not validate the argument count in 
{{TypeInferenceOperandInference}} which results in bugs like e.g. 
[FLINK-33248]. We do run the check already in {{TypeInferenceUtil}} when 
running inference for Table API so we should do the same in 
{{TypeInferenceOperandInference}} case.

We could expose {{TypeInferenceUtil#validateArgumentCount}} and call it. If the 
check fails, we should not adapt {{operandTypes}}




--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [VOTE] FLIP-239: Port JDBC Connector to FLIP-27-143

[Sergey Nuyanzin]

+1 (binding)

On Thu, Oct 12, 2023 at 10:44 AM Martijn Visser 
wrote:

> +1 (binding)
>
> On Thu, Oct 12, 2023 at 8:12 AM Samrat Deb  wrote:
> >
> > +1 (non binding )
> >
> > Bests,
> > Samrat
> >
> > On Thu, Oct 12, 2023 at 11:14 AM Jing Ge 
> wrote:
> >
> > > +1(binding) Thanks!
> > >
> > > Best regards,
> > > Jing
> > >
> > > On Wed, Oct 11, 2023 at 9:34 AM Yuepeng Pan 
> wrote:
> > >
> > > > +1(non-binding)
> > > > Thanks for your driving the voting thread.
> > > >
> > > > Best Regards.
> > > > Yuepeng Pan
> > > >
> > > > On 2023/10/06 16:33:40 Joao Boto wrote:
> > > > > Hi all, Thank you to everyone for the feedback on FLIP-239[1].
> Based on
> > > > the
> > > > > discussion thread [2] and some offline discussions, we have come
> to a
> > > > > consensus on the design and are ready to take a vote to contribute
> this
> > > > to
> > > > > Flink. I'd like to start a vote for it. The vote will be open for
> at
> > > > least
> > > > > 72 hours(excluding weekends, unless there is an objection or an
> > > > > insufficient number of votes. [1]
> > > > >
> > > >
> > >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=217386271
> > > > > [2]
> https://lists.apache.org/thread/yx833h5h3fjlyor0bfm32chy3sjw8hwt
> > > > Best,
> > > > > Joao Boto
> > > > >
> > > >
> > >
>


-- 
Best regards,
Sergey

[jira] [Created] (FLINK-33254) Improve speed of compile step

[Matthias Pohl (Jira)]

Matthias Pohl created FLINK-33254:
-

 Summary: Improve speed of compile step
 Key: FLINK-33254
 URL: https://issues.apache.org/jira/browse/FLINK-33254
 Project: Flink
  Issue Type: Sub-task
Reporter: Matthias Pohl


There were issues with the compilation step where I initially thought that it's 
due to the parallelization of the compilation (which is odd). This issue is 
about investigating how to do the compilation and forwarding the artifacts in 
the right way to the downstream jobs.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: Re: [DISCUSS] FLIP-373: Support Configuring Different State TTLs using SQL Hint

[Zakelly Lan]

Thanks Jane for clarifying this. I'm ok with keeping the current hint
pattern with the table name specified by key. Just thinking if there
is another simpler way to define the hint. What if an omitted key hint
only applied for tables from the current query block?


Thanks.


Best,
Zakelly

On Wed, Oct 11, 2023 at 11:25 PM Jane Chan  wrote:
>
> Thank you all for the valuable feedback.
>
> There is a difference when users incorrectly use hints, and there are two
> possible scenarios:
> <1> STATE_TTL hint can be applied to the current query block but with an
> invalid key or value. In this case, the validation exception will be
> thrown. The HintOptionChecker will throw exceptions if the options are
> empty or the value is an invalid duration. And JoinHintResolver will throw
> exceptions if the hint key(table name/alias, etc.) does not exist. So does
> for the group aggregate.
>
> <2> STATE_TTL hint cannot be applied to the current query block, e.g.,
> SELECT /*+ STATE_TTL('MyTable' = '2h') */ * a, b, c FROM MyTable. In this
> case, the hint is ignored. This is a by-design behavior according to
> FLIP-229 [1].
>
> I've made the modifications to the FLIP regarding exception handling. I
> would appreciate it if you could review it again.
>
> @Xuyang
>
> >  I notice that using STATE_TTL hints wrongly will not throw any
> > exceptions. But it seems that in the current join hint scenario, if user
> > uses an unknown table name as the chosen side, a validation exception will
> > be thrown. Maybe we should distinguish which exceptions need to be thrown
> > explicitly.
>
>
> You're right; the STATE_TTL hint semantic check should throw exceptions
> like join hints.
>
> @Feng @Yun
>
> > since there is no exception thrown when the STATE hint is set incorrectly,
> > should we somehow show that the TTL setting has taken effect?
>
> For instance, exhibiting the TTL option within the operator's description?
>
>
> We can throw explicit exceptions for scenario #1. For scenario #2, I prefer
> to align the behavior for current query block hints for now (and we may
> open a separate discussion in the future). On the other hand, from the
> implementation aspect, it is not easy to do so. Taking the example of
> deduplication mentioned earlier, the hint is lost before it propagates to
> the FlinkLogicalRank node, making it challenging to capture the exception.
>
> @Zakelly
>
> > would it be possible to provide a simple hint that allows the omission of
> > the key? For example, something like "SELECT /+ STATE_TTL('1h')/", which
> > would specify the TTL for all states in the 'SELECT' clause.
>
>
> I'm afraid the hint key cannot be omitted. E.g., the join operator is a
> TwoInputStreamOperator; if we want to specify different state TTLs for the
> left and right input, we need to inform the planner of the ordinal info
> (LEFT v.s. RIGHT). On the other hand, the SELECT clause may contain several
> query blocks, while the hint scope is designed to apply to the current
> query block [2] to prevent the hint on the outer query block from
> propagating to the inner query block. For the use case where users need to
> specify the TTL for all states in the 'SELECT' clause, it is preferable to
> modify the compiled plan instead of using hints.
>
> @ConradJam
> I share the same opinion with @Yun that this is a nice-to-have feature. Big
> +1 for the follow-up on FLINK-33230. Users can now use the COMPILE PLAN
> statement to serialize the query to a JSON string or file and then check
> the state metadata to ensure the hint is applied.
>
> [1]
> https://cwiki.apache.org/confluence/display/FLINK/FLIP-229%3A+Introduces+Join+Hint+for+Flink+SQL+Batch+Job
> 
> [2]
> https://nightlies.apache.org/flink/flink-docs-master/docs/dev/table/sql/queries/hints/#query-hints
> 
>
> Best,
> Jane
>
>
> On Wed, Oct 11, 2023 at 8:49 PM Yun Tang  wrote:
>
> > I think showing the TTL for operators is a nice-to-have feature, not a
> > must one in this FLIP. We can still get the information from the operator
> > descriptions.
> >
> > And I think we can continue the TTL showing work based on FLINK-33230 [1].
> >
> > Last but not least, I prefer to throw exceptions if the TTL configuration
> > is mistakenly used as it will affect the data correctness.
> >
> > [1] https://issues.apache.org/jira/browse/FLINK-33230
> >
> > Best
> > Yun Tang
> > 
> > From: ConradJam 
> > Sent: Wednesday, October 11, 2023 20:30
> > To: dev@flink.apache.org 
> > Subject: Re: Re: [DISCUSS] FLIP-373: Support Configuring Different State
> > TTLs using SQL Hint
> >
> > +1 TTL shows the state ttl for operators in Flink web ui can be know what
> > operator state
> >
> > Zakelly Lan  于2023年10月11日周三 19:14写道：
> >
> > > Hi Jane,
> > >
> > > The fine-grained TTL 

[jira] [Created] (FLINK-33253) test_pyflink.sh fails: zip is missing in Docker image

[Matthias Pohl (Jira)]

Matthias Pohl created FLINK-33253:
-

 Summary: test_pyflink.sh fails: zip is missing in Docker image
 Key: FLINK-33253
 URL: https://issues.apache.org/jira/browse/FLINK-33253
 Project: Flink
  Issue Type: Sub-task
Reporter: Matthias Pohl


https://github.com/XComp/flink/actions/runs/6459928600/job/17538354449#step:14:7360
{code}
/root/flink/flink-end-to-end-tests/test-scripts/test_pyflink.sh: line 107: zip: 
command not found
{code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

RE: FW: RE: Close orphaned/stale PRs

[David Radley]

Hi everyone,
Martjin, I like your ideas. I think these labels will help, make it obvious 
what work is actionable. I really feel these sort of process improvements will 
incrementally help work to flow through appropriately.

2 additional thoughts – I hope these help this discussion:

  *   A triaged label on the issue would indicate that a maintainer has agreed 
this is a valid issue – this would be a better pool of issues for contributors 
to pickup. I am not sure if maintainers currently do this sort of work.
  *   I like the codeowners idea; did you find a way though this within the 
Apache rules? An extension to this is that increasingly we are moving out parts 
of the code from the main Flink repository to other repositories; would this be 
doable. Could experts in those repositories be given write access to those 
repos; so that each non core repo can work through its issues and merge its prs 
more independently. This is how LF project Egeria works with its connectors and 
UIS;  I guess the concern is that in ASF these people would need to be  
committers, or could they be a committer on a subset of repos. Another way to 
manage who can merge prs is to gate the pr process using git actions, so that 
if an approved approver indicates a pr is good then the raiser can merge – this 
would give us granularity on write access – PyTorch follows this sort of 
process.

  kind regards, David.


From: Martijn Visser 
Date: Thursday, 12 October 2023 at 10:32
To: dev@flink.apache.org 
Subject: [EXTERNAL] Re: FW: RE: Close orphaned/stale PRs
Hi everyone,

I'm overall +1 on Ryan's comment.
When we're talking about component ownership, I've started a
discussion on the Infra mailing list in the beginning of the year on
it. In principle, the "codeowners" idea goes against ASF principles.

Let's summarize things:
1. From a project perspective, we can have a discussion about closing
PRs automatically that a) are not followed-up within X number of days
after a review and/or b) PRs that don't have a passing build and/or
don't follow contribution guidelines and/or C) need to be rebased
2. In order to help understand which PRs are OK to get reviewed, we
could consider automatically adding a label "Ready for review" in case
1b (passing build/contribution guidelines met) is the case.
3. In order to help contributors, we could consider automatically
adding a label in case their PR isn't mergeable for the situations
that are displayed in situation 1

When that's done, we can see what the effect is on the PRs queue.

Best regards,

Martijn

On Wed, Oct 4, 2023 at 5:13 PM David Radley  wrote:
>
> Hi Ryan,
>
> I agree that good communication is key to determining what can be worked on.
>
> In terms of metrics , we can use the gh cli to list prs and we can export 
> issues from Jira. A view across them, you could join on the Flink issue (at 
> the start of the pr comment and the flink issue itself – you could then see 
> which prs have an assigned Jira would be expected to be reviewed. There is no 
> explicit reviewer field in the Jira issue; I am not sure if we can easily get 
> this info without having a custom field (which others have tried).
>
> In terms of what prs a committer could / should review – I would think that 
> component ownership helps scope the subset of prs to review / merge.
>
> Kind regards, David.
>
>
> From: Ryan Skraba 
> Date: Wednesday, 4 October 2023 at 15:09
> To: dev@flink.apache.org 
> Subject: [EXTERNAL] Re: FW: RE: Close orphaned/stale PRs
> Hey, this has been an interesting discussion -- this is something that
> has been on my mind as an open source contributor and committer (I'm
> not a Flink committer).
>
> A large number of open PRs doesn't _necessarily_ mean a project is
> unhealthy or has technical debt. If it's fun and easy to get your
> contribution accepted and committed, even for a small fix, you're more
> likely to raise another PR, and another.  I wouldn't be surprised if
> there's a natural equilibrium where adding capacity to smoothly review
> and manage more PRs cause more PRs to be submitted.  Everyone wins!
>
> I don't think there's a measure for the "average PR lifetime", or
> "time to first comment", but those would be more interesting things to
> know and those are the worrisome ones.
>
> As a contributor, I'm pretty willing to wait as long as necessary (and
> rebase and fix merge conflicts) if there's good communication in
> place. I'm pretty patient, especially if I knew that the PR would be
> looked at and merged for a specific fix version (for example).  I'd
> expect simple and obvious fixes with limited scope to take less time
> than a more complex, far-reaching change.  I'd probably appreciate
> that the boring-cyborg welcomes me on my first PR, but I'd be pretty
> irritated if any PR were closed without any human interaction.
>
> As a reviewer or committer, it's just overwhelming to see the big
> GitHub list, and sometimes it feels random just 

[jira] [Created] (FLINK-33252) LicenseChecker fails in GHA but succeeds in Azure

[Matthias Pohl (Jira)]

Matthias Pohl created FLINK-33252:
-

 Summary: LicenseChecker fails in GHA but succeeds in Azure
 Key: FLINK-33252
 URL: https://issues.apache.org/jira/browse/FLINK-33252
 Project: Flink
  Issue Type: Sub-task
  Components: Build System / CI
Reporter: Matthias Pohl


Both builds are based on 
[master@011b6b44|https://github.com/apache/flink/commit/011b6b44]:
 * [GitHub 
Actions|https://github.com/XComp/flink/actions/runs/6487689661/job/17620650207#step:8:41307]
 * [Azure 
CI|https://dev.azure.com/apache-flink/apache-flink/_build/results?buildId=53624=logs=52b61abe-a3cc-5bde-cc35-1bbe89bb7df5=54421a62-0c80-5aad-3319-094ff69180bb=43193]

The GitHub Actions run reports 12 severe issues where it's unclear where they 
are coming from:
{code:java}
23:30:45,534 WARN  org.apache.flink.tools.ci.licensecheck.LicenseChecker
[] - Found a total of 12 severe license issues {code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [Discuss] FLIP-366: Support standard YAML for FLINK configuration

[Junrui Lee]

Hi everyone,
Thanks for all the comments! Based on the discussion so far, I will proceed
to initiate the vote tomorrow if there are no further discussions or
objections.

Best regards,
Junrui

Junrui Lee  于2023年10月9日周一 11:52写道：

> Hi, Chesnay and David, sorry for the late reply.
>
> Thanks for your feedback about this FLIP.
>
> @Chesnay
>
> >> Personally I'd just name it "config.yaml"
> Thanks for your suggestions, I agree that "config.yaml" is a simpler and
> more intuitive name. I have updated the FLIP accordingly.
>
> >> In terms of scope, is the migration of existing e2e tests and the
> docker image to the new parser part of the FLIP?
> The migration of existing end-to-end tests and the docker image to the new
> parser is indeed included in the FLIP. Taking into account the difficulty
> of using shell scripts to modify configuration files that adhere to
> standard YAML syntax, I propose utilizing the
> org.apache.flink.runtime.util.bash.BashJavaUtils class as a unified utility
> for modifying the configuration file.
>
> In addition, considering that users may not only configure properties in
> the configuration file, but also use dynamic parameters like '-D' or
> configure the "with" clauses in FLINK SQL. When the default parser is
> changed to the standard YAML parser, the configOption whose value is List
> or Map types also needs to be modified accordingly. This migration cost is
> relatively high because users have to modify their code or command lines.
> To reduce migration costs while considering compatibility, I propose to
> add compatibility support in FLINK-1.X versions to parse old format List
> and Map values using the standard YAML parser. In case of an error while
> parsing List or Map configurations with the standard YAML parser, a WARNING
> log will be printed, and an attempt will be made to parse using the old
> parser. And this support will be removed in the FLINK-2.0 version.
>
> Do you think the aforementioned compatibility handling is necessary in
> order to reduce migration costs?  If you agree, I will also update this
> support in the FLIP under the migration section.
>
> @David
>
> >> could we write a migration tool, that would convert the old config
> files to the new format,
> I agree that providing a more user-friendly guidance for the migration is
> important. In the FLIP, we can include a user migration manual to help
> users with the migration process. This migration manual will be presented
> on the official FLINK website, making it easily accessible for users. And
> the migrated configuration files will adhere to standard YAML syntax, and
> users can validate them using various third-party YAML tools.
>
> Regarding the automated migration tool, I think it can be considered as a
> follow-up task rather than a requirement for the initial version. We can
> focus on implementing the migration manually first and then explore the
> possibility of automating it in future updates.
>
> Best,
> Junrui
>
> David Radley  于2023年10月3日周二 18:56写道：
>
>> Hi,
>> I agree this is a standardising, simplifying change for read,
>> simplifying programmatically authoring the config file as well.  As you
>> know the mapping for the old config form to the new form, could we write a
>> migration tool, that would convert the old config files to the new format,
>> with errors and warnings if the content is such that the user would need to
>> manually fix up the file.
>> If there are minimal user fixups, we should consider automatically
>> migrating the config file to the new format,
>> Kind regards, David.
>>
>>
>>
>>
>> From: Chesnay Schepler 
>> Date: Tuesday, 3 October 2023 at 11:17
>> To: dev@flink.apache.org 
>> Subject: [EXTERNAL] Re: [Discuss] FLIP-366: Support standard YAML for
>> FLINK configuration
>> It is a unfortunate that we'll need a separate config file but the FLIP
>> does a good job justifying it.
>>
>> Personally I'd just name it "config.yaml"; I never quite understood why
>> there was a flink prefix to begin with, and the current proposal
>> ("flink-configuration.yaml") seems unnecessarily long.
>>
>> For the deprecation process we could consider logging a warning if the
>> old parser is used.
>>
>> In terms of scope, is the migration of existing e2e tests and the docker
>> image to the new parser part of the FLIP?
>>
>> On 22/09/2023 09:32, Jane Chan wrote:
>> > Hi, Junrui,
>> >
>> > Sorry for the late reply. The update looks good to me and thanks for
>> your
>> > effort!
>> >
>> > Best,
>> > Jane
>> >
>> > On Fri, Sep 22, 2023 at 2:25 PM Yuxin Tan 
>> wrote:
>> >
>> >> Hi, Junrui
>> >>
>> >> +1 for the proposal.
>> >> Thanks for your effort.
>> >>
>> >> Best,
>> >> Yuxin
>> >>
>> >>
>> >> Samrat Deb  于2023年9月22日周五 13:23写道：
>> >>
>> >>> Hello Junrui,
>> >>>
>> >>> +1 for the proposal.
>> >>>
>> >>>
>> >>> Bests,
>> >>> Samrat
>> >>>
>> >>> On Fri, Sep 22, 2023 at 10:18 AM Shammon FY 
>> wrote:
>> >>>
>>  +1 for the proposal, thanks for driving.
>> 
>>  Bet,
>>  

[jira] [Created] (FLINK-33251) SQL Client query execution aborts after a few seconds: ConnectTimeoutException

[Robin Moffatt (Jira)]

Robin Moffatt created FLINK-33251:
-

 Summary: SQL Client query execution aborts after a few seconds: 
ConnectTimeoutException
 Key: FLINK-33251
 URL: https://issues.apache.org/jira/browse/FLINK-33251
 Project: Flink
  Issue Type: Bug
  Components: Table SQL / Client
Affects Versions: 1.17.1, 1.18.0
 Environment: Macbook Pro 

Apple M1 Max
 
{code:java}
$ uname -a
Darwin asgard08 23.0.0 Darwin Kernel Version 23.0.0: Fri Sep 15 14:41:43 PDT 
2023; root:xnu-10002.1.13~1/RELEASE_ARM64_T6000 arm64
{code}

Reporter: Robin Moffatt
 Attachments: log.zip

If I run a streaming query from an unbounded connector from the SQL Client, it 
bombs out after ~15 seconds.

{code:java}
[ERROR] Could not execute SQL statement. Reason:
org.apache.flink.shaded.netty4.io.netty.channel.ConnectTimeoutException: 
connection timed out: localhost/127.0.0.1:52596
{code}

This *doesn't* happen on 1.16.2. It *does* happen on *1.17.1* and *1.18* that I 
have just built locally (git repo hash `9b837727b6d`). 

The corresponding task's status in the Web UI shows as `CANCELED`. 

---

h2. To reproduce

Launch local cluster and SQL client

{code}
➜  flink-1.18-SNAPSHOT ./bin/start-cluster.sh 
Starting cluster.
Starting standalonesession daemon on host asgard08.
Starting taskexecutor daemon on host asgard08.
➜  flink-1.18-SNAPSHOT ./bin/sql-client.sh
[…]
Flink SQL>
{code}

Set streaming mode and result mode

{code:sql}
Flink SQL> SET 'execution.runtime-mode' = 'STREAMING';
[INFO] Execute statement succeed.

Flink SQL> SET 'sql-client.execution.result-mode' = 'changelog';
[INFO] Execute statement succeed.
{code}

Define a table to read data from CSV files in a folder

{code:sql}
CREATE TABLE firewall (
  event_time STRING,
  source_ip  STRING,
  dest_ipSTRING,
  source_prt INT,
  dest_prt   INT
) WITH (
  'connector' = 'filesystem',
  'path' = 'file:///tmp/firewall/',
  'format' = 'csv',
  'source.monitor-interval' = '1' -- unclear from the docs what the unit is here
);
{code}

Create a CSV file to read in

{code:bash}
$ mkdir /tmp/firewall

$ cat > /tmp/firewall/data.csv <
{code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: Propose a release of flink-connector-opensearch

[Martijn Visser]

Hi Leonid,

I'm +1 for releasing a new version, but I would wait until Flink 1.18 is
released so it can be done in one go.

Best regards,

Martijn

On Thu, Aug 24, 2023 at 5:17 PM Ilyevsky, Leonid 
wrote:

> Hi everybody,
>
> I would like to propose a release of
> https://github.com/apache/flink-connector-opensearch which includes the
> latest enhancements and fixes.
>
> I believe the latest commit
> https://github.com/apache/flink-connector-opensearch/commit/d853e3d6be3e0f15e25c1220800b7d5fcf152c43
> adds a very important feature from which many users will benefit. It
> provides the ability to optionally set a custom FailureHandler in the
> client code to handle the errors passed from the OpenSearch server. See
> https://issues.apache.org/jira/browse/FLINK-30998 .
>
> I suggest to nominate
> https://issues.apache.org/jira/secure/ViewProfile.jspa?name=martijnvisser
> as a release manager.
>
>
>
>
>
> Kind regards,
>
> Leonid Ilyevsky
>
> Technology Consultant
>
>
>
> O
>
> +1-646-660-8087
>
>
>
> Liquidnet
>
>
>
> 
>
>
>
> Classification: Public
>
>
> 
> Disclaimer
> This message may contain confidential, proprietary or legally privileged
> information. No confidentiality or privilege is waived by misdirection. The
> contents of this message are for the use of the intended recipient only. If
> you are not the intended recipient, you are expressly prohibited from
> using, disclosing, reproducing or distributing the contents of this message
> in any way, either directly or indirectly. If you have received this in
> error, please contact the sender by return email, then delete this email
> and any copies of it from your system immediately. Please also destroy any
> hard copies of the message. Views expressed herein are those of the
> individual sender and are not given or endorsed by Liquidnet Europe
> Limited, through whom this message is sent, unless otherwise clearly
> indicated within the above message.
>
> Internet communications cannot be guaranteed to be secure or error-free.
> Although this information has been compiled with great care, Liquidnet
> Europe Limited shall not accept any responsibility for any errors,
> omissions or other inaccuracies, nor for the consequences thereof, and
> shall not be bound in any way to the contents of this email. We believe,
> but do not warrant that this email and any attachments are virus free. You
> should take full responsibility for virus checking.
>
> Liquidnet Europe Limited. Authorised and regulated by the Financial
> Conduct Authority in the UK. Member of the London Stock Exchange and a
> remote member of the SIX Swiss Exchange. Licensed by the Financial Sector
> Conduct Authority in South Africa. Registered in England and Wales no.
> 4232799. Liquidnet is part of TP ICAP Group plc..
>

Re: [Re-DISCUSS] FLIP-202: Introduce ClickHouse Connector

[Martijn Visser]

Hi Conrad,

I think we need that confirmation from the original author as part of
this discussion thread.

Best regards,

Martijn

On Tue, Oct 3, 2023 at 4:13 AM ConradJam  wrote:
>
> After email communication between me and the author of the warehouse, he
> has agreed to donate to Apache Flink and participate in the design of the
> solution.
>
> @Martlin @Leonard
> Yes, it can be said that for clickhouse's connector solution [1] we still
> refer to part of the code and implementation of the existing clickhouse
> connector [2]. To be precise, we should replace some outdated
> implementations. During this process, the author and I hope to make the
> following improvements based on the current warehouse after synchronizing
> information via email:
> ● ClickHouse JDBC is updated to the latest (0.4.6[3] is stable and
> available as of the email deadline)
> ● Support bool type, delete statement, grpc, tcp
> ● Implement new Clickhouse Sink Api (to be confirmed)
>
> [1] https://cwiki.apache.org/confluence/display/FLINK/%5BDRAFT%5D+FLIP-202
> %3A+Introduce+ClickHouse+Connector
> [2] https://github.com/itinycheng/flink-connector-clickhouse
> [3] https://github.com/ClickHouse/clickhouse-java/releases
>
>
>
> Martijn Visser  于2023年9月20日周三 21:20写道：
>
> > Hi ConradJam,
> >
> > The FLIP still references the unofficial "flink-clickhouse-connector"
> > which I don't really understand: you want to build a new
> > implementation for this connector, right?
> >
> > Best regards,
> >
> > Martijn
> >
> > On Thu, Sep 7, 2023 at 12:12 PM ConradJam  wrote:
> > >
> > > Does anyone else have an opinion on this part? If not I will start
> > > voting.Comment collection will be open again
> >
>
>
> --
> Best
>
> ConradJam

Re: FW: RE: Close orphaned/stale PRs

[Martijn Visser]

Hi everyone,

I'm overall +1 on Ryan's comment.
When we're talking about component ownership, I've started a
discussion on the Infra mailing list in the beginning of the year on
it. In principle, the "codeowners" idea goes against ASF principles.

Let's summarize things:
1. From a project perspective, we can have a discussion about closing
PRs automatically that a) are not followed-up within X number of days
after a review and/or b) PRs that don't have a passing build and/or
don't follow contribution guidelines and/or C) need to be rebased
2. In order to help understand which PRs are OK to get reviewed, we
could consider automatically adding a label "Ready for review" in case
1b (passing build/contribution guidelines met) is the case.
3. In order to help contributors, we could consider automatically
adding a label in case their PR isn't mergeable for the situations
that are displayed in situation 1

When that's done, we can see what the effect is on the PRs queue.

Best regards,

Martijn

On Wed, Oct 4, 2023 at 5:13 PM David Radley  wrote:
>
> Hi Ryan,
>
> I agree that good communication is key to determining what can be worked on.
>
> In terms of metrics , we can use the gh cli to list prs and we can export 
> issues from Jira. A view across them, you could join on the Flink issue (at 
> the start of the pr comment and the flink issue itself – you could then see 
> which prs have an assigned Jira would be expected to be reviewed. There is no 
> explicit reviewer field in the Jira issue; I am not sure if we can easily get 
> this info without having a custom field (which others have tried).
>
> In terms of what prs a committer could / should review – I would think that 
> component ownership helps scope the subset of prs to review / merge.
>
> Kind regards, David.
>
>
> From: Ryan Skraba 
> Date: Wednesday, 4 October 2023 at 15:09
> To: dev@flink.apache.org 
> Subject: [EXTERNAL] Re: FW: RE: Close orphaned/stale PRs
> Hey, this has been an interesting discussion -- this is something that
> has been on my mind as an open source contributor and committer (I'm
> not a Flink committer).
>
> A large number of open PRs doesn't _necessarily_ mean a project is
> unhealthy or has technical debt. If it's fun and easy to get your
> contribution accepted and committed, even for a small fix, you're more
> likely to raise another PR, and another.  I wouldn't be surprised if
> there's a natural equilibrium where adding capacity to smoothly review
> and manage more PRs cause more PRs to be submitted.  Everyone wins!
>
> I don't think there's a measure for the "average PR lifetime", or
> "time to first comment", but those would be more interesting things to
> know and those are the worrisome ones.
>
> As a contributor, I'm pretty willing to wait as long as necessary (and
> rebase and fix merge conflicts) if there's good communication in
> place. I'm pretty patient, especially if I knew that the PR would be
> looked at and merged for a specific fix version (for example).  I'd
> expect simple and obvious fixes with limited scope to take less time
> than a more complex, far-reaching change.  I'd probably appreciate
> that the boring-cyborg welcomes me on my first PR, but I'd be pretty
> irritated if any PR were closed without any human interaction.
>
> As a reviewer or committer, it's just overwhelming to see the big
> GitHub list, and sometimes it feels random just "picking one near the
> top" to look at.  In projects where I have the committer role, I
> sometimes feel more badly about work I'm *not* doing than the work I'm
> getting done! This isn't sustainable either.  A lot of people on the
> project are volunteering after hours, and grooming, reviewing and
> commenting PRs shouldn't be a thankless, unending job to feel bad
> about.
>
> As a contributor, one "magic" solution that I'd love to see is a
> better UI that could show (for example) tentative "review dates", like
> the number at a butcher shop, and proposed reviewers.
>
> If I was committing to reviewing a PR every day, it would be great if
> I could know which ones were the best "next" candidates to review: the
> one waiting longest, or a new, critical fix in my domain.  As it
> stands, there's next to no chance that the PRs in the middle of the
> list are going to get any attention, but closing them stand to lose
> valuable work or (worse) turn off a potential contributor forever.
>
> Taking a look at some open PRs that I authored or interacted with: I
> found one that should have been closed, one that was waiting for MY
> attention for a merge-squash-rebase (oops), another where I made some
> requested changes and it's back in review limbo.  Unfortunately, I
> don't think any of these would have been brought to my attention by a
> nag-bot. I don't think I'm alone; automated emails get far less
> attention  with sometime not giving automated emails much attention.
>
> OK, one more thing to think about: some underrepresented groups in
> tech can 

Re: Kafka Connector

[Martijn Visser]

Hi David,

I didn't see this message, but I did go over the Flink repo yesterday
and closed off all PRs that were relevant to the Kafka connector.
Removing the label won't help much, if a user classifies a Jira ticket
as Connector/Kafka but opens a PR in the Flink repo, the label will be
re-added.

Best regards,

Martijn

On Wed, Oct 4, 2023 at 5:44 PM David Radley  wrote:
>
> Hi,
> I was looking at the pr backlog in the Flink repository and realise that 
> there are 51 hits  on the search 
> https://github.com/apache/flink/pulls?q=is%3Apr+is%3Aopen+kafka-connector.
>
> And 25 hits on
> https://github.com/apache/flink/pulls?q=is%3Apr+is%3Aopen+kafka-connector+label%3Acomponent%3DConnectors%2FKafka
>
> I am updating the prs on the Kafka connector component indicating that the pr 
> is no longer relevant to this repo.
> I suggest we close out these prs, as they cannot be merged with a pointer to 
> the other repo -to port any required code changes.
>
> Once the prs have been removed, I suggest we also remove the connector/kafka 
> component from the core flink repo – so no new prs come in with it.
>
> What do you think?
> Kind regards, David.
>
>
>
>
>
>
> Unless otherwise stated above:
>
> IBM United Kingdom Limited
> Registered in England and Wales with number 741598
> Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU

Re: UDF support parity in Scala

[Martijn Visser]

Hi,

It could very well be that there isn't parity for Scala, given that
Scala is a 2nd class citizen in Flink (Java and Python are 1st class).
With Flink 2.0, support for the Scala APIs will also be removed.

Best regards,

Martijn

On Fri, Oct 6, 2023 at 10:48 PM mojhaha kiklasds
 wrote:
>
> Hi team,
>
> I am looking to understand parity in Table API and SQL API.
> Would you say that we have parity for UDF?
> I see the TableAggregateFunction can not be represented in Flink SQL but
> only in Table API. Have you known it to work like other UDFs?

Re: [VOTE] FLIP-239: Port JDBC Connector to FLIP-27-143

[Martijn Visser]

+1 (binding)

On Thu, Oct 12, 2023 at 8:12 AM Samrat Deb  wrote:
>
> +1 (non binding )
>
> Bests,
> Samrat
>
> On Thu, Oct 12, 2023 at 11:14 AM Jing Ge  wrote:
>
> > +1(binding) Thanks!
> >
> > Best regards,
> > Jing
> >
> > On Wed, Oct 11, 2023 at 9:34 AM Yuepeng Pan  wrote:
> >
> > > +1(non-binding)
> > > Thanks for your driving the voting thread.
> > >
> > > Best Regards.
> > > Yuepeng Pan
> > >
> > > On 2023/10/06 16:33:40 Joao Boto wrote:
> > > > Hi all, Thank you to everyone for the feedback on FLIP-239[1]. Based on
> > > the
> > > > discussion thread [2] and some offline discussions, we have come to a
> > > > consensus on the design and are ready to take a vote to contribute this
> > > to
> > > > Flink. I'd like to start a vote for it. The vote will be open for at
> > > least
> > > > 72 hours(excluding weekends, unless there is an objection or an
> > > > insufficient number of votes. [1]
> > > >
> > >
> > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=217386271
> > > > [2]https://lists.apache.org/thread/yx833h5h3fjlyor0bfm32chy3sjw8hwt
> > > Best,
> > > > Joao Boto
> > > >
> > >
> >

[jira] [Created] (FLINK-33250) HBase Connector should directly depend on 3rd-party libs instead of flink-shaded repo

[Martijn Visser (Jira)]

Martijn Visser created FLINK-33250:
--

 Summary: HBase Connector should directly depend on 3rd-party libs 
instead of flink-shaded repo
 Key: FLINK-33250
 URL: https://issues.apache.org/jira/browse/FLINK-33250
 Project: Flink
  Issue Type: Sub-task
  Components: Connectors / HBase
Reporter: Martijn Visser
Assignee: Martijn Visser






--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [VOTE] FLIP-239: Port JDBC Connector to FLIP-27-143

[Samrat Deb]

+1 (non binding )

Bests,
Samrat

On Thu, Oct 12, 2023 at 11:14 AM Jing Ge  wrote:

> +1(binding) Thanks!
>
> Best regards,
> Jing
>
> On Wed, Oct 11, 2023 at 9:34 AM Yuepeng Pan  wrote:
>
> > +1(non-binding)
> > Thanks for your driving the voting thread.
> >
> > Best Regards.
> > Yuepeng Pan
> >
> > On 2023/10/06 16:33:40 Joao Boto wrote:
> > > Hi all, Thank you to everyone for the feedback on FLIP-239[1]. Based on
> > the
> > > discussion thread [2] and some offline discussions, we have come to a
> > > consensus on the design and are ready to take a vote to contribute this
> > to
> > > Flink. I'd like to start a vote for it. The vote will be open for at
> > least
> > > 72 hours(excluding weekends, unless there is an objection or an
> > > insufficient number of votes. [1]
> > >
> >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=217386271
> > > [2]https://lists.apache.org/thread/yx833h5h3fjlyor0bfm32chy3sjw8hwt
> > Best,
> > > Joao Boto
> > >
> >
>