[jira] [Created] (FLINK-31831) TaskManagerDisconnectOnShutdownITCase.testTaskManagerProcessFailure is unstable

[Sergey Nuyanzin (Jira)]

Sergey Nuyanzin created FLINK-31831:
---

 Summary: 
TaskManagerDisconnectOnShutdownITCase.testTaskManagerProcessFailure is unstable
 Key: FLINK-31831
 URL: https://issues.apache.org/jira/browse/FLINK-31831
 Project: Flink
  Issue Type: Bug
  Components: Runtime / Coordination
Reporter: Sergey Nuyanzin


https://dev.azure.com/apache-flink/apache-flink/_build/results?buildId=48212=logs=39d5b1d5-3b41-54dc-6458-1e2ddd1cdcf3=0c010d0c-3dec-5bf1-d408-7b18988b1b2b=8399

{noformat}
Apr 18 04:17:09 [ERROR] 
org.apache.flink.test.recovery.TaskManagerDisconnectOnShutdownITCase.testTaskManagerProcessFailure
  Time elapsed: 2.844 s  <<< FAILURE!
Apr 18 04:17:09 java.lang.AssertionError: Failed to initialize the cluster 
entrypoint .
Apr 18 04:17:09 at org.junit.Assert.fail(Assert.java:89)
Apr 18 04:17:09 at 
org.apache.flink.test.recovery.TaskManagerDisconnectOnShutdownITCase.testTaskManagerProcessFailure(TaskManagerDisconnectOnShutdownITCase.java:136)
Apr 18 04:17:09 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native 
Method)
Apr 18 04:17:09 at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
Apr 18 04:17:09 at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)


{noformat}



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

Re: Re: [VOTE] FLIP-302: Support TRUNCATE TABLE statement in batch mode

[Shammon FY]

+1 (no-binding)

Best,
Shammon FY

On Tue, Apr 18, 2023 at 12:56 PM Jacky Lau  wrote:

> +1 (no-binding)
>
> Best,
> Jacky Lau
>
> Jingsong Li  于2023年4月18日周二 11:57写道：
>
> > +1
> >
> > On Tue, Apr 18, 2023 at 9:39 AM Aitozi  wrote:
> > >
> > > +1
> > >
> > > Best,
> > > Aitozi
> > >
> > > ron  于2023年4月18日周二 09:18写道：
> > > >
> > > > +1
> > > >
> > > >
> > > > > -原始邮件-
> > > > > 发件人: "Lincoln Lee" 
> > > > > 发送时间: 2023-04-18 09:08:08 (星期二)
> > > > > 收件人: dev@flink.apache.org
> > > > > 抄送:
> > > > > 主题: Re: [VOTE] FLIP-302: Support TRUNCATE TABLE statement in batch
> > mode
> > > > >
> > > > > +1 (binding)
> > > > >
> > > > > Best,
> > > > > Lincoln Lee
> > > > >
> > > > >
> > > > > yuxia  于2023年4月17日周一 23:54写道：
> > > > >
> > > > > > Hi all.
> > > > > >
> > > > > > Thanks for all the feedback on FLIP-302: Support TRUNCATE TABLE
> > statement
> > > > > > in batch mode [1].
> > > > > > Based on the discussion [2], we have come to a consensus, so I
> > would like
> > > > > > to start a vote.
> > > > > >
> > > > > > The vote will last for at least 72 hours unless there is an
> > objection or
> > > > > > insufficient votes.
> > > > > >
> > > > > > [1]:
> > > > > >
> >
> https://cwiki.apache.org/confluence/display/FLINK/FLIP-302%3A+Support+TRUNCATE+TABLE+statement+in+batch+mode
> > > > > > [2]: [
> > https://lists.apache.org/thread/m4r3wrd7p96wdst3nz3ncqzog6kf51cf |
> > > > > > https://lists.apache.org/thread/m4r3wrd7p96wdst3nz3ncqzog6kf51cf
> ]
> > > > > >
> > > > > >
> > > > > > Best regards,
> > > > > > Yuxia
> > > > > >
> > > >
> > > >
> > > > --
> > > > Best,
> > > > Ron
> >
>

Re: [DISCUSS] Status of Statefun Project

[Galen Warren]

Are there any next steps here?

On Mon, Apr 3, 2023, 12:46 PM Galen Warren  wrote:

> Thanks for bringing this up.
>
> I'm currently using Statefun, and I've made a few small code contributions
> over time. All of my PRs have been merged into master and most have been
> released, but a few haven't been part of a release yet. Most recently, I
> helped upgrade Statefun to be compatible with Flink 1.15.2, which was
> merged last October but hasn't been released. (And, of course, there have
> been more Flink releases since then.)
>
> IMO, the main thing driving the need for ongoing Statefun releases -- even
> in the absence of any new feature development -- is that there is typically
> a bit of work to do to make Statefun compatible with each new Flink
> release. This usually involves updating dependency versions and sometimes
> some simple code changes, a common example being adapting to changes in
> Flink config parameters that have changed from, say, delimited strings to
> arrays.
>
> I'd be happy to continue to make the necessary changes to Statefun to be
> compatible with each new Flink release, but I don't have the committer
> rights that would allow me to release the code.
>
>
>
>
>
> On Mon, Apr 3, 2023 at 5:02 AM Martijn Visser 
> wrote:
>
>> Hi everyone,
>>
>> I want to open a discussion on the status of the Statefun Project [1] in
>> Apache Flink. As you might have noticed, there hasn't been much
>> development
>> over the past months in the Statefun repository [2]. There is currently a
>> lack of active contributors and committers who are able to help with the
>> maintenance of the project.
>>
>> In order to improve the situation, we need to solve the lack of committers
>> and the lack of contributors.
>>
>> On the lack of committers:
>>
>> 1. Ideally, there are some of the current Flink committers who have the
>> bandwidth and can help with reviewing PRs and merging them.
>> 2. If that's not an option, it could be a consideration that current
>> committers only approve and review PRs, that are approved by those who are
>> willing to contribute to Statefun and if the CI passes
>>
>> On the lack of contributors:
>>
>> 3. Next to having this discussion on the Dev and User mailing list, we can
>> also create a blog with a call for new contributors on the Flink project
>> website, send out some tweets on the Flink / Statefun twitter accounts,
>> post messages on Slack etc. In that message, we would inform how those
>> that
>> are interested in contributing can start and where they could reach out
>> for
>> more information.
>>
>> There's also option 4. where a group of interested people would split
>> Statefun from the Flink project and make it a separate top level project
>> under the Apache Flink umbrella (similar as recently has happened with
>> Flink Table Store, which has become Apache Paimon).
>>
>> If we see no improvements in the coming period, we should consider
>> sunsetting Statefun and communicate that clearly to the users.
>>
>> I'm looking forward to your thoughts.
>>
>> Best regards,
>>
>> Martijn
>>
>> [1] https://nightlies.apache.org/flink/flink-statefun-docs-master/
>> [2] https://github.com/apache/flink-statefun
>>
>

Re: Re: [VOTE] FLIP-302: Support TRUNCATE TABLE statement in batch mode

[Jacky Lau]

+1 (no-binding)

Best,
Jacky Lau

Jingsong Li  于2023年4月18日周二 11:57写道：

> +1
>
> On Tue, Apr 18, 2023 at 9:39 AM Aitozi  wrote:
> >
> > +1
> >
> > Best,
> > Aitozi
> >
> > ron  于2023年4月18日周二 09:18写道：
> > >
> > > +1
> > >
> > >
> > > > -原始邮件-
> > > > 发件人: "Lincoln Lee" 
> > > > 发送时间: 2023-04-18 09:08:08 (星期二)
> > > > 收件人: dev@flink.apache.org
> > > > 抄送:
> > > > 主题: Re: [VOTE] FLIP-302: Support TRUNCATE TABLE statement in batch
> mode
> > > >
> > > > +1 (binding)
> > > >
> > > > Best,
> > > > Lincoln Lee
> > > >
> > > >
> > > > yuxia  于2023年4月17日周一 23:54写道：
> > > >
> > > > > Hi all.
> > > > >
> > > > > Thanks for all the feedback on FLIP-302: Support TRUNCATE TABLE
> statement
> > > > > in batch mode [1].
> > > > > Based on the discussion [2], we have come to a consensus, so I
> would like
> > > > > to start a vote.
> > > > >
> > > > > The vote will last for at least 72 hours unless there is an
> objection or
> > > > > insufficient votes.
> > > > >
> > > > > [1]:
> > > > >
> https://cwiki.apache.org/confluence/display/FLINK/FLIP-302%3A+Support+TRUNCATE+TABLE+statement+in+batch+mode
> > > > > [2]: [
> https://lists.apache.org/thread/m4r3wrd7p96wdst3nz3ncqzog6kf51cf |
> > > > > https://lists.apache.org/thread/m4r3wrd7p96wdst3nz3ncqzog6kf51cf ]
> > > > >
> > > > >
> > > > > Best regards,
> > > > > Yuxia
> > > > >
> > >
> > >
> > > --
> > > Best,
> > > Ron
>

Re: Re: [VOTE] FLIP-302: Support TRUNCATE TABLE statement in batch mode

[Jingsong Li]

+1

On Tue, Apr 18, 2023 at 9:39 AM Aitozi  wrote:
>
> +1
>
> Best,
> Aitozi
>
> ron  于2023年4月18日周二 09:18写道：
> >
> > +1
> >
> >
> > > -原始邮件-
> > > 发件人: "Lincoln Lee" 
> > > 发送时间: 2023-04-18 09:08:08 (星期二)
> > > 收件人: dev@flink.apache.org
> > > 抄送:
> > > 主题: Re: [VOTE] FLIP-302: Support TRUNCATE TABLE statement in batch mode
> > >
> > > +1 (binding)
> > >
> > > Best,
> > > Lincoln Lee
> > >
> > >
> > > yuxia  于2023年4月17日周一 23:54写道：
> > >
> > > > Hi all.
> > > >
> > > > Thanks for all the feedback on FLIP-302: Support TRUNCATE TABLE 
> > > > statement
> > > > in batch mode [1].
> > > > Based on the discussion [2], we have come to a consensus, so I would 
> > > > like
> > > > to start a vote.
> > > >
> > > > The vote will last for at least 72 hours unless there is an objection or
> > > > insufficient votes.
> > > >
> > > > [1]:
> > > > https://cwiki.apache.org/confluence/display/FLINK/FLIP-302%3A+Support+TRUNCATE+TABLE+statement+in+batch+mode
> > > > [2]: [ https://lists.apache.org/thread/m4r3wrd7p96wdst3nz3ncqzog6kf51cf 
> > > > |
> > > > https://lists.apache.org/thread/m4r3wrd7p96wdst3nz3ncqzog6kf51cf ]
> > > >
> > > >
> > > > Best regards,
> > > > Yuxia
> > > >
> >
> >
> > --
> > Best,
> > Ron

[jira] [Created] (FLINK-31830) Coalesce on nested fields with different nullabilities will get wrong plan

[lincoln lee (Jira)]

lincoln lee created FLINK-31830:
---

 Summary: Coalesce on nested fields with different nullabilities 
will get wrong plan
 Key: FLINK-31830
 URL: https://issues.apache.org/jira/browse/FLINK-31830
 Project: Flink
  Issue Type: Bug
  Components: Table SQL / Planner
Affects Versions: 1.14.6
Reporter: lincoln lee


A test case similar to FLINK-31829, only changes the nullable field `a.np` to 
not null, will get a wrong plan in 1.14.x (reported from the community user):

{code}
  @Test
  def testCoalesceOnNestedColumns(): Unit = {
val tEnv = util.tableEnv
val tableDescriptor = TableDescriptor.forConnector("datagen")
.schema(Schema.newBuilder
.column("id", DataTypes.INT.notNull)
.column("a", DataTypes.ROW(DataTypes.FIELD("np", 
DataTypes.INT.notNull())).nullable)
.build)
.build
tEnv.createTemporaryTable("t1", tableDescriptor)
tEnv.createTemporaryTable("t2", tableDescriptor)
val res = tEnv.executeSql("EXPLAIN SELECT a.id, COALESCE(a.a.np, b.a.np) 
c1, IFNULL(a.a.np, b.a.np) c2 FROM t1 a left JOIN t2 b ON a.id=b.id where a.a 
is null or a.a.np is null")
res.print()
}  

== Abstract Syntax Tree ==
LogicalProject(id=[$0], c1=[CAST($1.np):INTEGER], c2=[IFNULL($1.np, $3.np)])
+- LogicalFilter(condition=[OR(IS NULL($1), IS NULL(CAST($1.np):INTEGER))])
   +- LogicalJoin(condition=[=($0, $2)], joinType=[left])
  :- LogicalTableScan(table=[[default_catalog, default_database, t1]])
  +- LogicalTableScan(table=[[default_catalog, default_database, t2]])
{code}

the top project in the ast is wrong:  `LogicalProject(id=[$0], 
c1=[CAST($1.np):INTEGER], c2=[IFNULL($1.np, $3.np)])`, the 
`c1=[CAST($1.np):INTEGER]` relate to `COALESCE(a.a.np, b.a.np) c1` is incorrect,
but this works fine when using sql ddl to create tables
{code}
  @Test
  def testCoalesceOnNestedColumns2(): Unit = {
val tEnv = util.tableEnv
tEnv.executeSql(
  s"""
 |create temporary table t1 (
 |  id int not null,
 |  a row
 |) with (
 | 'connector' = 'datagen'
 |)
 |""".stripMargin)
tEnv.executeSql(
  s"""
 |create temporary table t2 (
 |  id int not null,
 |  a row
 |) with (
 | 'connector' = 'datagen'
 |)
 |""".stripMargin)
val res = tEnv.executeSql(
  "EXPLAIN SELECT a.id, COALESCE(a.a.np, b.a.np) c1, IFNULL(a.a.np, b.a.np) 
c2 FROM t1 a left JOIN t2 b ON a.id=b.id where a.a is null or a.a.np is null")
res.print()
  }
{code}
from 1.15, the coalesce will be a new builtin function, and the ast looks 
correct in version 1.15+, while before 1.15 it was rewritten as `case when`






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

Re: [DISCUSS FLINKSQL PARALLELISM]

[yuxia]

It makes sense to support operator parallelism. 
But just FYI, for sink,  you can use sink.parallelism[1] to set sink 
parallelism. 

[1] 
https://nightlies.apache.org/flink/flink-docs-master/docs/connectors/table/filesystem/#sink-parallelism

Best regards,
Yuxia

- 原始邮件 -
发件人: "ron9 liu" 
收件人: "dev" 
发送时间: 星期二, 2023年 4 月 18日 上午 9:37:05
主题: Re: [DISCUSS FLINKSQL PARALLELISM]

Hi, Green

Thanks for driving this discussion, in batch mode we have the Adaptive
Batch Scheduler which automatically derives operator parallelism based on
data volume at runtime, so we don't need to care about the parallelism.
However, in stream mode, currently, Flink SQL can only set the parallelism
of an operator globally, and many users would like to set the parallelism
of an operator individually, which seems to be a pain point at the moment,
and it would make sense to support set parallelism at operator granularity.
Do you have any idea about the solution for this problem?

Best,
Ron


GREEN <1286649...@qq.com.invalid> 于2023年4月14日周五 16:03写道：

> Problem：
>
>
> Currently, FlinkSQL can set a unified parallelism in the job,it
> cannot set parallelism for each operator.
> This can cause resource waste On the occasion of high
> parallelism and small data volume.there may also be too many small
> file for writing HDFS Scene.
>
>
> Solution：
> I can modify FlinkSQL to support operator parallelism.Is it meaningful to
> do this？Let's discuss.

Re: Re: [VOTE] FLIP-302: Support TRUNCATE TABLE statement in batch mode

[Aitozi]

+1

Best,
Aitozi

ron  于2023年4月18日周二 09:18写道：
>
> +1
>
>
> > -原始邮件-
> > 发件人: "Lincoln Lee" 
> > 发送时间: 2023-04-18 09:08:08 (星期二)
> > 收件人: dev@flink.apache.org
> > 抄送:
> > 主题: Re: [VOTE] FLIP-302: Support TRUNCATE TABLE statement in batch mode
> >
> > +1 (binding)
> >
> > Best,
> > Lincoln Lee
> >
> >
> > yuxia  于2023年4月17日周一 23:54写道：
> >
> > > Hi all.
> > >
> > > Thanks for all the feedback on FLIP-302: Support TRUNCATE TABLE statement
> > > in batch mode [1].
> > > Based on the discussion [2], we have come to a consensus, so I would like
> > > to start a vote.
> > >
> > > The vote will last for at least 72 hours unless there is an objection or
> > > insufficient votes.
> > >
> > > [1]:
> > > https://cwiki.apache.org/confluence/display/FLINK/FLIP-302%3A+Support+TRUNCATE+TABLE+statement+in+batch+mode
> > > [2]: [ https://lists.apache.org/thread/m4r3wrd7p96wdst3nz3ncqzog6kf51cf |
> > > https://lists.apache.org/thread/m4r3wrd7p96wdst3nz3ncqzog6kf51cf ]
> > >
> > >
> > > Best regards,
> > > Yuxia
> > >
>
>
> --
> Best,
> Ron

Re: [DISCUSS FLINKSQL PARALLELISM]

[liu ron]

Hi, Green

Thanks for driving this discussion, in batch mode we have the Adaptive
Batch Scheduler which automatically derives operator parallelism based on
data volume at runtime, so we don't need to care about the parallelism.
However, in stream mode, currently, Flink SQL can only set the parallelism
of an operator globally, and many users would like to set the parallelism
of an operator individually, which seems to be a pain point at the moment,
and it would make sense to support set parallelism at operator granularity.
Do you have any idea about the solution for this problem?

Best,
Ron


GREEN <1286649...@qq.com.invalid> 于2023年4月14日周五 16:03写道：

> Problem：
>
>
> Currently, FlinkSQL can set a unified parallelism in the job,it
> cannot set parallelism for each operator.
> This can cause resource waste On the occasion of high
> parallelism and small data volume.there may also be too many small
> file for writing HDFS Scene.
>
>
> Solution：
> I can modify FlinkSQL to support operator parallelism.Is it meaningful to
> do this？Let's discuss.

[jira] [Created] (FLINK-31829) Conversion to relational algebra failed to preserve datatypes' nullabilities

[lincoln lee (Jira)]

lincoln lee created FLINK-31829:
---

 Summary:  Conversion to relational algebra failed to preserve 
datatypes' nullabilities
 Key: FLINK-31829
 URL: https://issues.apache.org/jira/browse/FLINK-31829
 Project: Flink
  Issue Type: Bug
  Components: Table SQL / Planner
Affects Versions: 1.17.0
Reporter: lincoln lee
 Fix For: 1.18.0


AssertionError when run such a case:
{code}
  @Test
  def testCoalesceOnNestedColumns(): Unit = {
val tEnv = util.tableEnv
val tableDescriptor = TableDescriptor
  .forConnector("datagen")
  .schema(
Schema.newBuilder
  .column("id", DataTypes.INT.notNull)
  .column("a", DataTypes.ROW(DataTypes.FIELD("np", 
DataTypes.INT)).nullable)
  .build)
  .build
tEnv.createTemporaryTable("t1", tableDescriptor)
tEnv.createTemporaryTable("t2", tableDescriptor)
val res = tEnv.executeSql(
  "EXPLAIN SELECT a.id, COALESCE(a.a.np, b.a.np) c1, IFNULL(a.a.np, b.a.np) 
c2 FROM t1 a left JOIN t2 b ON a.id=b.id where a.a is null or a.a.np is null")
res.print()
  }
{code}

stack:
{code}
java.lang.AssertionError: Conversion to relational algebra failed to preserve 
datatypes:
validated type:
RecordType(INTEGER B1, INTEGER NOT NULL B2, INTEGER BenchmarkId1, INTEGER NOT 
NULL BenchmarkIdWithIfNull, INTEGER NOT NULL BenchmarkId2) NOT NULL
converted type:
RecordType(INTEGER NOT NULL B1, INTEGER NOT NULL B2, INTEGER BenchmarkId1, 
INTEGER NOT NULL BenchmarkIdWithIfNull, INTEGER NOT NULL BenchmarkId2) NOT NULL
rel:
LogicalProject(B1=[$4.BenchmarkId], B2=[$2.BenchmarkId], BenchmarkId1=[IF(IS 
NOT NULL($4), $4.BenchmarkId, IF(true, $2.BenchmarkId, null:INTEGER))], 
BenchmarkIdWithIfNull=[IFNULL($4.BenchmarkId, $2.BenchmarkId)], 
BenchmarkId2=[COALESCE($4.BenchmarkId, $2.BenchmarkId)])
  LogicalFilter(condition=[OR(IS NULL($4), IS NULL($4.BenchmarkId))])
LogicalJoin(condition=[=($3, $0)], joinType=[left])
  LogicalJoin(condition=[=($1, $0)], joinType=[inner])
LogicalTableScan(table=[[default_catalog, default_database, dbo_book]])
LogicalTableScan(table=[[default_catalog, default_database, 
static_book]])
  LogicalTableScan(table=[[default_catalog, default_database, 
onebook_book_benchmark]])


at 
org.apache.calcite.sql2rel.SqlToRelConverter.checkConvertedType(SqlToRelConverter.java:500)
at 
org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:611)
at 
org.apache.flink.table.planner.calcite.FlinkPlannerImpl.org$apache$flink$table$planner$calcite$FlinkPlannerImpl$$rel(FlinkPlannerImpl.scala:216)
at 
org.apache.flink.table.planner.calcite.FlinkPlannerImpl.rel(FlinkPlannerImpl.scala:192)
at 
org.apache.flink.table.planner.operations.SqlNodeConvertContext.toRelRoot(SqlNodeConvertContext.java:56)
at 
org.apache.flink.table.planner.operations.converters.SqlQueryConverter.convertSqlNode(SqlQueryConverter.java:48)
at 
org.apache.flink.table.planner.operations.converters.SqlNodeConverters.convertSqlNode(SqlNodeConverters.java:65)
at 
org.apache.flink.table.planner.operations.SqlNodeToOperationConversion.convertValidatedSqlNode(SqlNodeToOperationConversion.java:281)
at 
org.apache.flink.table.planner.operations.SqlNodeToOperationConversion.convert(SqlNodeToOperationConversion.java:271)
at 
org.apache.flink.table.planner.delegation.ParserImpl.parse(ParserImpl.java:106)
at 
org.apache.flink.table.api.internal.TableEnvironmentImpl.sqlQuery(TableEnvironmentImpl.java:665)
{code}

but the equivalent tests using sql ddl to create table works fine:
{code}
  @Test
  def testCoalesceOnNestedColumns2(): Unit = {
val tEnv = util.tableEnv
tEnv.executeSql(s"""
   |create temporary table t1 (
   |  id int not null,
   |  a row
   |) with (
   | 'connector' = 'datagen'
   |)
   |""".stripMargin)
tEnv.executeSql(s"""
   |create temporary table t2 (
   |  id int not null,
   |  a row
   |) with (
   | 'connector' = 'datagen'
   |)
   |""".stripMargin)
val res = tEnv.executeSql(
  "EXPLAIN SELECT a.id, COALESCE(a.a.np, b.a.np) c1, IFNULL(a.a.np, b.a.np) 
c2 FROM t1 a left JOIN t2 b ON a.id=b.id where a.a is null or a.a.np is null")
res.print()
  }


== Abstract Syntax Tree ==
LogicalProject(id=[$0], c1=[COALESCE($1.np, $3.np)], c2=[IFNULL($1.np, $3.np)])
+- LogicalFilter(condition=[OR(IS NULL($1), IS NULL($1.np))])
   +- LogicalJoin(condition=[=($0, $2)], joinType=[left])
  :- LogicalTableScan(table=[[default_catalog, default_database, t1]])
  +- LogicalTableScan(table=[[default_catalog, 

Re: [DISCUSS] FLIP-302: Support TRUNCATE TABLE statement

[yuxia]

Hi, all.
I started a vote for this FLIP[1], please vote there[2] or ask additional
questions here[3].

[1] 
https://cwiki.apache.org/confluence/display/FLINK/FLIP-302%3A+Support+TRUNCATE+TABLE+statement+in+batch+mode
[2] https://lists.apache.org/thread/fosvz0zcyfn6bp6vz2oxl45vq9qhkn2v
[3] https://lists.apache.org/thread/m4r3wrd7p96wdst3nz3ncqzog6kf51cf

Best regards,
Yuxia

- 原始邮件 -
发件人: "Jark Wu" 
收件人: "dev" 
发送时间: 星期五, 2023年 4 月 14日 下午 11:04:58
主题: Re: [DISCUSS] FLIP-302: Support TRUNCATE TABLE statement

Hi Yuxia,

Thank you for the updating. That sounds good to me.

Best,
Jark

> 2023年4月14日 19:00，yuxia  写道：
> 
> Hi, Jark.
> I'm expecting if the "executeTruncation" returns false, Flink will throw an 
> generic exception like "Fail to execute truncate table statement."
> But the connector implementation can also throw more specific exception like 
> "Fail to execute truncate table statement for it table is been writing by 
> other jobs".
> 
> But after think it over, I'm afraid of the connector implementation will 
> always return false to make Flink itself construnct the exception which maybe 
> not very useful for it provides 
> much less exception message instead of throwing more specific exception.
> So I decide to change it to `void executeTruncation()` and reminder to throw 
> exception if truncate operation hasn't been executed successfully in the java 
> doc of the method.
> I had updated this FLIP.
> 
> 
> Best regards,
> Yuxia
> 
> - 原始邮件 -
> 发件人: "Jark Wu" 
> 收件人: "dev" 
> 发送时间: 星期五, 2023年 4 月 14日 下午 5:10:48
> 主题: Re: [DISCUSS] FLIP-302: Support TRUNCATE TABLE statement
> 
> The FLIP looks good to me. +1 to start a vote.
> 
> I just have a question: what will happen if the "executeTruncation" returns
> false without any exceptions?
> 
> Best,
> Jark
> 
> On Thu, 13 Apr 2023 at 19:59, Jing Ge  wrote:
> 
>> Thanks Yuxia for the clarification and FLIP update. The FLIP looks good!
>> 
>> Best regards,
>> Jing
>> 
>> On Mon, Apr 10, 2023 at 3:51 AM yuxia  wrote:
>> 
>>> 1:
>>> Actaully, considering the Flink's implementation, Flink just provides
>>> Truncate Table syntax to help user simlify data management as said in
>> this
>>> FLIP and push the implementation of Truncate Table to external connector.
>>> Normally, the effect of TRUENCATE TABLE is same as Drop Table + Create
>>> Table. But the real difference/benefit depends on the implementation of
>> the
>>> external connector.
>>> For example, for DROP Table statement, some external connectors may also
>>> drop the view related or other things.
>>> But for Truncate Table, the connectors may just delete all data without
>>> other operations.
>>> 
>>> 
>>> 2:
>>> At very begining, I'm thinking about in which case user may want to
>>> truncate a temporary table.
>>> I thought users can always create a table in catalog(if the table doesn't
>>> exist in a catalog) and truncate the table. So I tend not to expose it to
>>> user.
>>> But after I think it over again, I think it may be reasonable to support
>>> truncate a temporary table for the case that user just want to delete all
>>> datas from a table in an external storage without storing the metadata of
>>> the table in a catalog so that the other user/session can't see the
>> metada.
>>> I think we can relax to the constraint to support truncate temporary
>>> table. Now, I update it to the FLIP.
>>> 
>>> 
>>> 3:
>>> Thanks for your input, I agree that we can dicuss it in a different FLIP.
>>> 
>>> 
>>> 
>>> Best regards,
>>> Yuxia
>>> 
>>> - 原始邮件 -
>>> 发件人: "Jing Ge" 
>>> 收件人: "dev" 
>>> 发送时间: 星期六, 2023年 4 月 08日 上午 3:05:11
>>> 主题: Re: [DISCUSS] FLIP-302: Support TRUNCATE TABLE statement
>>> 
>>> Hi yuxia,
>>> 
>>> Thanks for raising this topic. It is indeed a useful feature. +1 for
>>> having it in Flink. I have some small questions and it would be great if
>>> related information could be described in the FLIP.
>>> 
>>> 1. Speaking of data warehouse use cases, what is the benefit of using
>>> TRUNCATE table over DROP table + CREATE table IF NOT EXISTS with the
>>> consideration of concrete Flink implementations? What would be the
>>> suggestion for users to use TRUNCATE instead of DROP + CREATE... and
>>> vise versa?
>>> 
>>> 2. Since some engines support it, would you like to describe your
>>> thought about why TRUNCATE table does not support temporary table?
>>> 
>>> 3. The partition support is an important feature, afaic. It might
>>> deserve a different FLIP and consider e.g.: TRUNCATE TABLE
>>> tt_dw_usr_exp_xxx PARTITION(dt='20230303') and ALTER TABLE
>>> tt_dw_usr_exp_xxx DROP IF EXISTS PARTITION(dt='20230303').
>>> 
>>> Looking forward to your thoughts. Thanks!
>>> 
>>> Best regards,
>>> 
>>> Jing
>>> 
>>> On 4/7/23 05:04, Jingsong Li wrote:
 +1 for voting.
 
 Best,
 Jingsong
 
 On Thu, Apr 6, 2023 at 4:52 PM yuxia 
>>> wrote:
> Hi everyone.
> 
> If there are no other questions or concerns for the FLIP[1], I'd like
>>> to start 

Re: Re: [VOTE] FLIP-302: Support TRUNCATE TABLE statement in batch mode

[ron]

+1


> -原始邮件-
> 发件人: "Lincoln Lee" 
> 发送时间: 2023-04-18 09:08:08 (星期二)
> 收件人: dev@flink.apache.org
> 抄送: 
> 主题: Re: [VOTE] FLIP-302: Support TRUNCATE TABLE statement in batch mode
> 
> +1 (binding)
> 
> Best,
> Lincoln Lee
> 
> 
> yuxia  于2023年4月17日周一 23:54写道：
> 
> > Hi all.
> >
> > Thanks for all the feedback on FLIP-302: Support TRUNCATE TABLE statement
> > in batch mode [1].
> > Based on the discussion [2], we have come to a consensus, so I would like
> > to start a vote.
> >
> > The vote will last for at least 72 hours unless there is an objection or
> > insufficient votes.
> >
> > [1]:
> > https://cwiki.apache.org/confluence/display/FLINK/FLIP-302%3A+Support+TRUNCATE+TABLE+statement+in+batch+mode
> > [2]: [ https://lists.apache.org/thread/m4r3wrd7p96wdst3nz3ncqzog6kf51cf |
> > https://lists.apache.org/thread/m4r3wrd7p96wdst3nz3ncqzog6kf51cf ]
> >
> >
> > Best regards,
> > Yuxia
> >


--
Best,
Ron

Re: [VOTE] FLIP-302: Support TRUNCATE TABLE statement in batch mode

[Lincoln Lee]

+1 (binding)

Best,
Lincoln Lee


yuxia  于2023年4月17日周一 23:54写道：

> Hi all.
>
> Thanks for all the feedback on FLIP-302: Support TRUNCATE TABLE statement
> in batch mode [1].
> Based on the discussion [2], we have come to a consensus, so I would like
> to start a vote.
>
> The vote will last for at least 72 hours unless there is an objection or
> insufficient votes.
>
> [1]:
> https://cwiki.apache.org/confluence/display/FLINK/FLIP-302%3A+Support+TRUNCATE+TABLE+statement+in+batch+mode
> [2]: [ https://lists.apache.org/thread/m4r3wrd7p96wdst3nz3ncqzog6kf51cf |
> https://lists.apache.org/thread/m4r3wrd7p96wdst3nz3ncqzog6kf51cf ]
>
>
> Best regards,
> Yuxia
>

[jira] [Created] (FLINK-31828) List field in a POJO data stream results in table program compilation failure

[Vladimir Matveev (Jira)]

Vladimir Matveev created FLINK-31828:


 Summary: List field in a POJO data stream results in table program 
compilation failure
 Key: FLINK-31828
 URL: https://issues.apache.org/jira/browse/FLINK-31828
 Project: Flink
  Issue Type: Bug
  Components: Table SQL / Runtime
Affects Versions: 1.16.1
 Environment: Java 11
Flink 1.16.1
Reporter: Vladimir Matveev
 Attachments: MainPojo.java, generated-code.txt, stacktrace.txt

Suppose I have a POJO class like this:

{code:java}
public class Example {
private String key;
private List> values;

// getters, setters, equals+hashCode omitted
}
{code}

When a DataStream with this class is converted to a table, and some operations 
are performed on it, it results in an exception which explicitly says that I 
should file a ticket:

{noformat}
Caused by: org.apache.flink.api.common.InvalidProgramException: Table program 
cannot be compiled. This is a bug. Please file an issue.
{noformat}

Please find the example Java code and the full stack trace attached.

>From the exception and generated code it seems that Flink is upset with the 
>list field being treated as an array - but I cannot have an array type there 
>in the real code.

Also note that if I _don't_ specify the schema explicitly, it then maps the 
{{values}} field to a `RAW('java.util.List', '...')` type, which also does not 
work correctly and fails the job in case of even simplest operations like 
printing.



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

Re: [DISCUSS] FLIP-287: Extend Sink#InitContext to expose ExecutionConfig and JobID

[Tzu-Li (Gordon) Tai]

Hi,

Sorry for chiming in late.

I'm not so sure that exposing ExecutionConfig / ReadExecutionConfig
directly through Sink#InitContext is the right thing to do.

1. A lot of the read-only getter methods on ExecutionConfig are irrelevant
for sinks. Expanding the scope of the InitContext interface with so many
irrelevant methods is probably going to make writing unit tests a pain.

2. There's actually a few getter methods on `InitContext` that have
duplicate/redundant info for what ExecutionConfig exposes. For example,
InitContext#getNumberOfParallelSubtasks and InitContext#getAttemptNumber
currently exist and it can be confusing if users find 2 sources of that
information (either via the `InitContext` and via the wrapped
`ExecutionConfig`).

All in all, it feels like `Sink#InitContext` was introduced initially as a
means to selectively only expose certain information to sinks.

It looks like right now, the only requirement is that some sinks require 1)
isObjectReuseEnabled, and 2) TypeSerializer for the input type. Would it
make sense to follow the original intent and only selectively expose these?
For 1), we can just add a new method to `InitContext` and forward the
information from `ExecutionConfig` accessible at the operator level.
For 2), would it make sense to create the serializer at the operator level
and then provide it through `InitContext`?

Thanks,
Gordon

On Mon, Apr 17, 2023 at 8:23 AM Zhu Zhu  wrote:

> We can let the `InitContext` return `ExecutionConfig` in the interface.
> However, a `ReadableExecutionConfig` implementation should be returned
> so that exceptions will be thrown if users tries to modify the
> `ExecutionConfig`.
>
> We can rework all the setters of `ExecutionConfig` to internally invoke a
> `setConfiguration(...)` method. Then the `ReadableExecutionConfig` can
> just override that method. But pay attention to a few exceptional
> setters, i.e. those for globalJobParameters and serializers.
>
> We should also explicitly state in the documentation of
> `InitContext #getExecutionConfig()`, that the returned `ExecutionConfig`
> is unmodifiable.
>
> Thanks,
> Zhu
>
> João Boto  于2023年4月17日周一 16:51写道：
> >
> > Hi Zhu,
> >
> > Thanks for you time for reviewing this.
> >
> > Extending ´ExecutionConfig´ will allow to modify the values in the
> config (this is what we want to prevent with Option2)
> >
> > To extend the ExecutionConfig is not simpler to do Option1 (expose
> ExecutionConfig directly).
> >
> > Regards
> >
> >
> >
> > On 2023/04/03 09:42:28 Zhu Zhu wrote:
> > > Hi João,
> > >
> > > Thanks for creating this FLIP!
> > > I'm overall +1 for it to unblock the migration of sinks to SinkV2.
> > >
> > > Yet I think it's better to let the `ReadableExecutionConfig` extend
> > > `ExecutionConfig`, because otherwise we have to introduce a new method
> > > `TypeInformation#createSerializer(ReadableExecutionConfig)`. The new
> > > method may require every `TypeInformation` to implement it, including
> > > Flink built-in ones and custom ones, otherwise exceptions will happen.
> > > That goal, however, is pretty hard to achieve.
> > >
> > > Thanks,
> > > Zhu
> > >
> > > João Boto  于2023年2月28日周二 23:34写道：
> > > >
> > > > I have update the FLIP with the 2 options that we have discussed..
> > > >
> > > > Option 1: Expose ExecutionConfig directly on InitContext
> > > > this have a minimal impact as we only have to expose the new methods
> > > >
> > > > Option 2: Expose ReadableExecutionConfig on InitContext
> > > > with this option we have more impact as we need to add a new method
> to TypeInformation and change all implementations (current exists 72
> implementations)
> > > >
> > > > Waiting for feedback or concerns about the two options
> > >
>

Re: [VOTE] Release flink-connector-rabbitmq v3.0.1, release candidate #1

[Ryan Skraba]

Hello!  +1 (non-binding)

I've validated the source for the RC1:
flink-connector-rabbitmq-3.0.1-src.tgz
* The sha512 checksum is OK.
* The source file is signed correctly.
* The signature A5F3BCE4CBE993573EC5966A65321B8382B219AF is found in the
KEYS file, and on https://keys.openpgp.org
* The source file is consistent with the Github tag v3.0.1-rc1, which
corresponds to commit 9827e71662c8f155cda5efe5ebbac804fd0fd8e2
   - The files explicitly excluded by create_pristine_sources (such as
.gitignore and the submodule tools/releasing/shared) are not present.
* Has a LICENSE file and a NOTICE file.  The sql-connector has a
NOTICE file for bundled artifacts.
* Does not contain any compiled binaries.

* The sources can be compiled and tests pass with flink.version 1.17.0 and
flink.version 1.16.1

* Nexus has three staged artifact ids for 3.0.1-1.16 and 3.0.1-1.17
 - flink-connector-rabbitmq-parent (only .pom)
 - flink-connector-rabbitmq (.jar, -sources.jar, -javadoc.jar and .pom)
 - flink-sql-connector-rabbitmq (.jar, -sources.jar and .pom)
* All 16 files have been signed with the same key as above, and have
correct sha1 and md5 checksums.

I didn't run any additional smoke tests other than the integration test
cases.

A couple minor points, but nothing that would block this release.

- like flink-connector-gcp-pubsub-parent, the
flink-connector-rabbitmq-parent:3.0.1-1.17 pom artifact has the
flink.version set to 1.16.0, which might be confusing.
- the NOTICE file for sql-connector has the wrong year.

All my best and thanks for the release.

Ryan


On Thu, Apr 13, 2023 at 4:45 PM Martijn Visser 
wrote:

> Hi everyone,
> Please review and vote on the release candidate #1 for the version 3.0.1,
> as follows:
> [ ] +1, Approve the release
> [ ] -1, Do not approve the release (please provide specific comments)
>
> This version is compatible with Flink 1.16.x and Flink 1.17.x
>
> The complete staging area is available for your review, which includes:
> * JIRA release notes [1],
> * the official Apache source release to be deployed to dist.apache.org
> [2],
> which are signed with the key with fingerprint
> A5F3BCE4CBE993573EC5966A65321B8382B219AF [3],
> * all artifacts to be deployed to the Maven Central Repository [4],
> * source code tag v3.0.1-rc1 [5],
> * website pull request listing the new release [6].
>
> The vote will be open for at least 72 hours. It is adopted by majority
> approval, with at least 3 PMC affirmative votes.
>
> Thanks,
> Release Manager
>
> [1]
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315522=12352699
> [2]
>
> https://dist.apache.org/repos/dist/dev/flink/flink-connector-rabbitmq-3.0.1-rc1
> [3] https://dist.apache.org/repos/dist/release/flink/KEYS
> [4]
> https://repository.apache.org/content/repositories/orgapacheflink-1615/
> [5]
> https://github.com/apache/flink-connector-rabbitmq/releases/tag/v3.0.1-rc1
> [6] https://github.com/apache/flink-web/pull/639
>

Re: Need Help with Slack Invite Link

[yuxia]

HI, welcome. Here is my invitation link.
https://join.slack.com/t/apache-flink/shared_invite/zt-1tbdyh3aa-8pWXQDw2PXKreTCk6sV9Tg

Best regards,
Yuxia

- 原始邮件 -
发件人: "Madhur Pyasi" 
收件人: "dev" 
发送时间: 星期日, 2023年 4 月 16日 上午 5:03:07
主题: Need Help with Slack Invite Link

Hello Flink Community,
I am trying to use the slack invite to join the Flink workspace but the
link is expired. Can somebody please share a new link or invite me (
mdhr.py...@gmail.com) to the workspace?

Wish you a fun weekend and look forward to learning from everyone here.

-Madhur

Re: Need Help with Slack Invite Link

[Yun Tang]

Hi Madhur,

Could you try this invitation link: 
https://join.slack.com/t/apache-flink/shared_invite/zt-1ta0su2np-lCCV6xD7XeKjwQuHMOTBIA


I'll also prepare a PR to update the Flink's doc. BTW, the invitation link 
would expire in 30 days, which means we have to manually update the doc[1] each 
month. I'm not sure whether we could have better ideas to avoid this.

[1] https://flink.apache.org/community/#slack

Best
Yun Tang


From: Madhur Pyasi 
Sent: Sunday, April 16, 2023 5:03
To: dev@flink.apache.org 
Subject: Need Help with Slack Invite Link

Hello Flink Community,
I am trying to use the slack invite to join the Flink workspace but the
link is expired. Can somebody please share a new link or invite me (
mdhr.py...@gmail.com) to the workspace?

Wish you a fun weekend and look forward to learning from everyone here.

-Madhur

[VOTE] FLIP-302: Support TRUNCATE TABLE statement in batch mode

[yuxia]

Hi all. 

Thanks for all the feedback on FLIP-302: Support TRUNCATE TABLE statement in 
batch mode [1]. 
Based on the discussion [2], we have come to a consensus, so I would like 
to start a vote. 

The vote will last for at least 72 hours unless there is an objection or 
insufficient votes. 

[1]: 
https://cwiki.apache.org/confluence/display/FLINK/FLIP-302%3A+Support+TRUNCATE+TABLE+statement+in+batch+mode
 
[2]: [ https://lists.apache.org/thread/m4r3wrd7p96wdst3nz3ncqzog6kf51cf | 
https://lists.apache.org/thread/m4r3wrd7p96wdst3nz3ncqzog6kf51cf ] 


Best regards, 
Yuxia 

[jira] [Created] (FLINK-31827) Incorrect estimation of the target data rate of a vertex when only a subset of its upstream vertex's output is consumed

[Zhanghao Chen (Jira)]

Zhanghao Chen created FLINK-31827:
-

 Summary: Incorrect estimation of the target data rate of a vertex 
when only a subset of its upstream vertex's output is consumed
 Key: FLINK-31827
 URL: https://issues.apache.org/jira/browse/FLINK-31827
 Project: Flink
  Issue Type: Bug
  Components: Autoscaler
Reporter: Zhanghao Chen
 Attachments: image-2023-04-17-23-37-35-280.png

Currently, the target data rate of a vertex = SUM(target data rate * 
input/output ratio) for all of its upstream vertices. This assumes that all 
output records of an upstream vertex is consumed by the downstream vertex. 
However, it does not always hold. Consider the following job plan generated by 
a Flink SQL job. The middle vertex contains multiple chained Calc(select xx) 
operators, each connecting to a separate downstream sink tasks. As a result, 
each sink task only consumes a sub-portion of the middle vertex's output.

To fix it, we need operator level edge info to infer the upstream-downstream 
relationship as well as operator level output metrics. The metrics part is easy 
but AFAIK, there's no way to get the operator level edge info from the Flink 
REST API yet.

!image-2023-04-17-23-37-35-280.png!



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

[jira] [Created] (FLINK-31826) Incorrect estimation of the target data rate of a vertex when only a subset of its upstream vertex's output is consumed

[Zhanghao Chen (Jira)]

Zhanghao Chen created FLINK-31826:
-

 Summary: Incorrect estimation of the target data rate of a vertex 
when only a subset of its upstream vertex's output is consumed
 Key: FLINK-31826
 URL: https://issues.apache.org/jira/browse/FLINK-31826
 Project: Flink
  Issue Type: Improvement
  Components: Autoscaler
Reporter: Zhanghao Chen
 Attachments: LHL7VKOG4B.jpg

Currently, a vertex's target data rate = the sum of its upstream vertex's 
target data rate * input/output ratio. This assumes that all of the upstream 
vertex output goes into the current vertex. However, it does not always hold. 
Consider the following job plan generated by a Flink SQL job. The vertex in the 
middle has multiple Calc(select xx) operators chained, each connects to a 
separate downstream tasks. The total num_rec_out_rate of the middle vertex = 
SUM num_rec_in_rate of its downstream tasks.

To fix this problem, we need operator level output metrics and edge info. The 
operator level metrics part is easy, but AFAIK, there's no way to get the 
operator level edge info from the current Flink REST APIs.

!LHL7VKOG4B.jpg!



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

Re: [DISCUSS] FLIP-287: Extend Sink#InitContext to expose ExecutionConfig and JobID

[Zhu Zhu]

We can let the `InitContext` return `ExecutionConfig` in the interface.
However, a `ReadableExecutionConfig` implementation should be returned
so that exceptions will be thrown if users tries to modify the
`ExecutionConfig`.

We can rework all the setters of `ExecutionConfig` to internally invoke a
`setConfiguration(...)` method. Then the `ReadableExecutionConfig` can
just override that method. But pay attention to a few exceptional
setters, i.e. those for globalJobParameters and serializers.

We should also explicitly state in the documentation of
`InitContext #getExecutionConfig()`, that the returned `ExecutionConfig`
is unmodifiable.

Thanks,
Zhu

João Boto  于2023年4月17日周一 16:51写道：
>
> Hi Zhu,
>
> Thanks for you time for reviewing this.
>
> Extending ´ExecutionConfig´ will allow to modify the values in the config 
> (this is what we want to prevent with Option2)
>
> To extend the ExecutionConfig is not simpler to do Option1 (expose 
> ExecutionConfig directly).
>
> Regards
>
>
>
> On 2023/04/03 09:42:28 Zhu Zhu wrote:
> > Hi João,
> >
> > Thanks for creating this FLIP!
> > I'm overall +1 for it to unblock the migration of sinks to SinkV2.
> >
> > Yet I think it's better to let the `ReadableExecutionConfig` extend
> > `ExecutionConfig`, because otherwise we have to introduce a new method
> > `TypeInformation#createSerializer(ReadableExecutionConfig)`. The new
> > method may require every `TypeInformation` to implement it, including
> > Flink built-in ones and custom ones, otherwise exceptions will happen.
> > That goal, however, is pretty hard to achieve.
> >
> > Thanks,
> > Zhu
> >
> > João Boto  于2023年2月28日周二 23:34写道：
> > >
> > > I have update the FLIP with the 2 options that we have discussed..
> > >
> > > Option 1: Expose ExecutionConfig directly on InitContext
> > > this have a minimal impact as we only have to expose the new methods
> > >
> > > Option 2: Expose ReadableExecutionConfig on InitContext
> > > with this option we have more impact as we need to add a new method to 
> > > TypeInformation and change all implementations (current exists 72 
> > > implementations)
> > >
> > > Waiting for feedback or concerns about the two options
> >

Re: Need Help with Slack Invite Link

[Hang Ruan]

Hi, Madhur,

I create a new invite link
https://join.slack.com/t/apache-flink/shared_invite/zt-1t4khgllz-Fm1CnXzdBbUchBz4HzJCAg
. Hope it is useful.

Best,
Hang

Madhur Pyasi  于2023年4月16日周日 05:03写道：

> Hello Flink Community,
> I am trying to use the slack invite to join the Flink workspace but the
> link is expired. Can somebody please share a new link or invite me (
> mdhr.py...@gmail.com) to the workspace?
>
> Wish you a fun weekend and look forward to learning from everyone here.
>
> -Madhur
>

Re: [VOTE] Apache Flink ML Release 2.2.0, release candidate #2

[Xingbo Huang]

Thanks Dong for driving this release.

+1 (binding)

- verify signatures and checksums
- pip install apache-flink-ml source package and run simple example
- download source code and build from source code
- review release notes

Best,
Xingbo

Guowei Ma  于2023年4月14日周五 15:54写道：

> Hi Dong,
>
> Thanks for driving this release!
>
> +1 (binding)
>
> * Checked JIRA release notes
> * Verified signature and checksum for the source
> * Download the source code and build the code with JDK8
> * Browsed through README.md files.
>
> Best,
> Guowei
>
>
> On Fri, Apr 14, 2023 at 2:48 PM Zhipeng Zhang 
> wrote:
>
> > Hi Dong,
> > Thanks for driving this release!
> >
> > +1 (non-binding)
> >
> > Here is what I have checked.
> > - Verified that the checksums and GPG files.
> > - Verified that the source distributions do not contain any binaries.
> > - Built the source distribution and run all unit tests.
> > - Verified that all POM files point to the same version.
> > - Browsed through JIRA release notes files.
> > - Browsed through README.md files.
> > - Verified the source code tag.
> >
> >
> > Dong Lin  于2023年4月13日周四 18:28写道：
> >
> > >
> > > Hi everyone,
> > >
> > > Please review and vote on the release candidate #2 for version 2.2.0 of
> > > Apache Flink ML as follows:
> > >
> > > [ ] +1, Approve the release
> > > [ ] -1, Do not approve the release (please provide specific comments)
> > >
> > > **Testing Guideline**
> > >
> > > You can find here [1] a page in the project wiki on instructions for
> > > testing.
> > >
> > > To cast a vote, it is not necessary to perform all listed checks, but
> > > please mention which checks you have performed when voting.
> > >
> > > **Release Overview**
> > >
> > > As an overview, the release consists of the following:
> > > a) Flink ML source release to be deployed to dist.apache.org
> > > b) Flink ML Python source distributions to be deployed to PyPI
> > > c) Maven artifacts to be deployed to the Maven Central Repository
> > >
> > > **Staging Areas to Review**
> > >
> > > The staging areas containing the above-mentioned artifacts are as
> > follows, for
> > > your review:
> > >
> > > - All artifacts for a) and b) can be found in the corresponding dev
> > repository
> > > at dist.apache.org [2], which are signed with the key with fingerprint
> > AFAC
> > > DB09 E6F0 FF28 C93D 64BC BEED 4F6C B9F7 7D0E [3]
> > > - All artifacts for c) can be found at the Apache Nexus Repository [4]
> > >
> > > **Other links for your review**
> > >
> > > - JIRA release notes [5]
> > > - Source code tag "release-2.2.0-rc2" [6]
> > > - PR to update the website Downloads page to include Flink ML links [7]
> > >
> > > **Vote Duration**
> > >
> > > The voting time will run for at least 72 hours. It is adopted by
> majority
> > > approval, with at least 3 PMC affirmative votes.
> > >
> > >
> > > Cheers,
> > > Dong
> > >
> > >
> > > [1]
> > https://cwiki.apache.org/confluence/display/FLINK/Verifying+a+Flink+ML+
> > > Release
> > > [2] https://dist.apache.org/repos/dist/dev/flink/flink-ml-2.2.0-rc2/
> > > [3] https://dist.apache.org/repos/dist/release/flink/KEYS
> > > [4]
> > https://repository.apache.org/content/repositories/orgapacheflink-1605/
> > > [5]
> > >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315522=12351884
> > > [6] https://github.com/apache/flink-ml/releases/tag/release-2.2.0-rc2
> > > [7] https://github.com/apache/flink-web/pull/630
> >
> >
> >
> > --
> > best,
> > Zhipeng
> >
>

[jira] [Created] (FLINK-31825) Stopping minikube fails with timeout

[Sergey Nuyanzin (Jira)]

Sergey Nuyanzin created FLINK-31825:
---

 Summary: Stopping minikube fails with timeout
 Key: FLINK-31825
 URL: https://issues.apache.org/jira/browse/FLINK-31825
 Project: Flink
  Issue Type: Bug
  Components: Connectors / Hadoop Compatibility, Tests
Affects Versions: 1.18.0
Reporter: Sergey Nuyanzin


Currently there is not so much information in logs...
{noformat}
Apr 13 01:27:02 * Stopping node "minikube"  ...
==
=== WARNING: This task took already 95% of the available time budget of 286 
minutes ===
==
==
The following Java processes are running (JPS)
==
243413 Jps
==
Printing stack trace of Java process 243413
==
243413: No such process
==
The following Java processes are running (JPS)
==
243516 Jps
==
Printing stack trace of Java process 243516
==
243516: No such process
=
=== WARNING: Killing task ===
=
Terminated
Apr 13 05:48:53 [FAIL] Test script contains errors.
{noformat}
https://dev.azure.com/apache-flink/apache-flink/_build/results?buildId=48096=logs=bbb1e2a2-a43c-55c8-fb48-5cfe7a8a0ca6=ba24ad14-6ea3-5ee3-c4ec-9e7cd2c9e754=5290



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

[jira] [Created] (FLINK-31824) flink sql TO_TIMESTAMP error

[leishuiyu (Jira)]

leishuiyu created FLINK-31824:
-

 Summary: flink sql TO_TIMESTAMP error
 Key: FLINK-31824
 URL: https://issues.apache.org/jira/browse/FLINK-31824
 Project: Flink
  Issue Type: Bug
  Components: Table SQL / Planner
Affects Versions: 1.14.3
 Environment: the verion is 1.14.3
Reporter: leishuiyu
 Fix For: 1.8.4
 Attachments: image-2023-04-17-20-07-17-569.png

 

 

 

 

 

 

!image-2023-04-17-20-07-17-569.png!



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

[jira] [Created] (FLINK-31823) RestHandlerConfigurationTest.testWebRescaleFeatureFlagWithReactiveMode is unstable

[Sergey Nuyanzin (Jira)]

Sergey Nuyanzin created FLINK-31823:
---

 Summary: 
RestHandlerConfigurationTest.testWebRescaleFeatureFlagWithReactiveMode is 
unstable
 Key: FLINK-31823
 URL: https://issues.apache.org/jira/browse/FLINK-31823
 Project: Flink
  Issue Type: Bug
  Components: Runtime / Web Frontend
Reporter: Sergey Nuyanzin


[https://dev.azure.com/apache-flink/apache-flink/_build/results?buildId=48177=logs=0e7be18f-84f2-53f0-a32d-4a5e4a174679=7c1d86e3-35bd-5fd5-3b7c-30c126a78702=8509]

{noformat}
Apr 16 01:15:08 [ERROR] Failures: 
Apr 16 01:15:08 [ERROR]   
RestHandlerConfigurationTest.testWebRescaleFeatureFlagWithReactiveMode:84 
Apr 16 01:15:08 expected: false
Apr 16 01:15:08  but was: true

{noformat}



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

Re: [Discussion] - Take findify/flink-scala-api under Flink umbrella

[Martijn Visser]

Hi Alexey,

I would argue that it's not a problem from Flink's source code, the problem
was that Scala introduced a binary incompatible change in Scala 2.12.8. If
Flink wanted to allow an upgrade, it would mean breaking snapshot
compatibility. That's why Flink is still bound to be used with Scala
2.12.7. Any user can still decide to use a newer version of Scala, by
compiling Flink with a newer Scala version.

Given that Akka and Spark are predominantly built in Scala, I don't think
they are comparable with Flink, being a Java-first application. I still
would have expected that if the Scala type system and object serialization
in Flink were a problem for the users, they would have contributed more on
the Scala wrapper.

The code example's readability ultimately becomes a matter of personal
preference imho. I don't think that this is an argument we should use in
the discussion.

I would +1 Chesnay's idea to fork the Findify project first under
flink-extended and have volunteers step up there. It makes it possible to
mature the wrappers and see how it develops and gets used in the future.

Best regards,

Martijn

On Mon, Apr 17, 2023 at 10:19 AM Alexey Novakov 
wrote:

> Hi Martijn,
>
> Thanks for your reply and attention.
>
> 1. As I read Nick's report here
> https://issues.apache.org/jira/browse/FLINK-13414?focusedCommentId=17257763=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17257763
> Scala maintainers were blocked by Flink's source code inability to migrate
> from Scala 2.11 to newer versions easily. One strong reason is extensive
> Scala Macros usage in Flink Scala API, so that eventually few other Scala
> users developed 3-rd party Flink Wrappers on top of Java API once it became
> possible.
>
> 2. Scala wrapper is still needed due to the Scala type system and object
> serialization in Flink. You can not easily searilie Scala product type by
> ONLY using Java API. Scala collection types also differ from standard Java
> collections. If that would not be needed, I of course would not even start
> this discussion and continue to use Java API from Scala. Same principles of
> Scala and Java classes separation you can find in Akka and Apache Spark
> code bases.
>
> 3. Another point I did not mention in the first email, the Scala code
> examples look much more readable in Flink docs thanks to concise language
> syntax. It would be very helpful to keep them in Flink and make sure they
> work with Scala 2.13. and Scala 3. We would need to make sure if a user
> uses Scala code example from Flink docs, it works with Scala latest version
> without any issue. Otherwise, Scala users will have issues if they won't
> use an extra Scala wrapper for Java API. If that Scala wrapper is not an
> official part of Flink project, then it will be unsafe to use Scala at all.
> Günter has mentioned about it in his reply as well.
>
> Best regards,
> Alexey
>
> On Mon, Apr 17, 2023 at 9:27 AM Martijn Visser 
> wrote:
>
>> Hi Alexey,
>>
>> > Taking into account my Scala experience for the last 8 years, I predict
>> these wrappers will eventually be abandoned, unless such a Scala library is
>> a part of some bigger community like ASF.
>>
>> For the past couple of years, there have been no maintainers for Scala in
>> the Flink community. It was one of the reasons to deprecate the Scala APIs.
>> Given that the wrappers don't seem to have taken off outside of Flink, why
>> would moving them under the AS resolve this?
>>
>> > Also, non-official Scala API will lead people to play safe and choose
>> Java API only, even if they did want that at the beginning.
>>
>> Why would that be a problem? Wouldn't the fact that there are no
>> maintainers for the Scala wrappers actually indicate that Scala users are
>> actually fine with using the Java APIs, because else there would have been
>> improvements made towards the Scala wrappers?
>>
>> Best regards,
>>
>> Martijn
>>
>> On Sun, Apr 16, 2023 at 11:47 AM David Morávek  wrote:
>>
>>> cc dev@f.a.o
>>>
>>> On Sun, Apr 16, 2023 at 11:42 AM David Morávek  wrote:
>>>
>>> > Hi Alexey,
>>> >
>>> > I'm a bit skeptical because, looking at the project, I see a couple of
>>> red
>>> > flags:
>>> >
>>> > - The project is inactive. The last release and commit are both from
>>> the
>>> > last May.
>>> > - The project has not been adapted for the last two Flink versions,
>>> which
>>> > signals a lack of users.
>>> > - All commits are by a single person, which could mean that there is no
>>> > community around the project.
>>> > - There was no external contribution (except the Scala bot).
>>> > - There is no fork of the project (except the Scala bot).
>>> >
>>> > >  As I know, FIndify does not want or cannot maintain this library.
>>> >
>>> > Who are the users of the library? I'd assume Findify no longer uses it
>>> if
>>> > they're abandoning it.
>>> >
>>> > > which would be similar to the StateFun
>>> >
>>> > We're currently dealing with a lack of maintainers for StateFun, so 

[jira] [Created] (FLINK-31822) Support configure maxRows when fetch result

[Feng Jin (Jira)]

Feng Jin created FLINK-31822:


 Summary: Support configure maxRows when fetch result 
 Key: FLINK-31822
 URL: https://issues.apache.org/jira/browse/FLINK-31822
 Project: Flink
  Issue Type: Improvement
  Components: Table SQL / Gateway
Affects Versions: 1.16.1
Reporter: Feng Jin


The default value of maxRow during fetch result is 5000. When requested from a 
web page, too many results in a single request may cause the web page to freeze.

 

Therefore, we can support configuring the maximum number of request results.



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

[jira] [Created] (FLINK-31821) FlinkSQL set parallelism for each operator.

[hanqing (Jira)]

hanqing created FLINK-31821:
---

 Summary: FlinkSQL set parallelism for each operator.
 Key: FLINK-31821
 URL: https://issues.apache.org/jira/browse/FLINK-31821
 Project: Flink
  Issue Type: New Feature
  Components: API / Core
Affects Versions: 1.16.1
Reporter: hanqing


Currently, FlinkSQL can  set a unified parallelism in the job,it cannot set 
parallelism for each operator.
This can cause resource waste  On the occasion of  high parallelism and small 
data volume.there may also be too many small file  for  writing HDFS Scene.



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

[jira] [Created] (FLINK-31820) Support data source sub-database and sub-table

[xingyuan cheng (Jira)]

xingyuan cheng created FLINK-31820:
--

 Summary: Support data source sub-database and sub-table
 Key: FLINK-31820
 URL: https://issues.apache.org/jira/browse/FLINK-31820
 Project: Flink
  Issue Type: Improvement
  Components: Connectors / JDBC
Reporter: xingyuan cheng


At present, apache/flink-connector-jdbc does not support sub-database and table 
sub-database. Now three commonly used databases Mysql, Postgres and Oracle 
support sub-database and sub-table

 

Taking oracle as an example, users only need to configure the following format 
to use

 
{code:java}
create table oracle_source (
EMPLOYEE_ID BIGINT,
START_DATE TIMESTAMP,
END_DATE TIMESTAMP,
JOB_ID VARCHAR,
DEPARTMENT_ID VARCHAR
) with (
type = 'oracle',    
url = 
'jdbc:oracle:thin:@//localhost:3306/order_([0-9]{1,}),jdbc:oracle:thin:@//localhost:3306/order_([0-9]{1,})',
   userName = 'userName',
password = 'password',
dbName = 'hr',
tableName = 'job_history',
timeField = 'START_DATE',
startTime = '2007-1-1 00:00:00'
); {code}
In the above code, the dbName attribute corresponds to the schema-name 
attribute in oracle or postgres, and the mysql database needs to manually 
specify the dbName

 

At the same time, I am also developing the CDAS whole database synchronization 
syntax for the company, and the data source supports sub-database and table as 
part of it. Add unit tests. For now, please keep this PR in draft status.



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

Re: [DISCUSS] FLIP-287: Extend Sink#InitContext to expose ExecutionConfig and JobID

[João Boto]

Hi Zhu,

Thanks for you time for reviewing this.

Extending ´ExecutionConfig´ will allow to modify the values in the config (this 
is what we want to prevent with Option2)

To extend the ExecutionConfig is not simpler to do Option1 (expose 
ExecutionConfig directly).

Regards



On 2023/04/03 09:42:28 Zhu Zhu wrote:
> Hi João,
> 
> Thanks for creating this FLIP!
> I'm overall +1 for it to unblock the migration of sinks to SinkV2.
> 
> Yet I think it's better to let the `ReadableExecutionConfig` extend
> `ExecutionConfig`, because otherwise we have to introduce a new method
> `TypeInformation#createSerializer(ReadableExecutionConfig)`. The new
> method may require every `TypeInformation` to implement it, including
> Flink built-in ones and custom ones, otherwise exceptions will happen.
> That goal, however, is pretty hard to achieve.
> 
> Thanks,
> Zhu
> 
> João Boto  于2023年2月28日周二 23:34写道：
> >
> > I have update the FLIP with the 2 options that we have discussed..
> >
> > Option 1: Expose ExecutionConfig directly on InitContext
> > this have a minimal impact as we only have to expose the new methods
> >
> > Option 2: Expose ReadableExecutionConfig on InitContext
> > with this option we have more impact as we need to add a new method to 
> > TypeInformation and change all implementations (current exists 72 
> > implementations)
> >
> > Waiting for feedback or concerns about the two options
> 

[jira] [Created] (FLINK-31819) Add document for using watermark advanced functions in sql

[Yuan Kui (Jira)]

Yuan Kui created FLINK-31819:


 Summary: Add document for using watermark advanced functions in sql
 Key: FLINK-31819
 URL: https://issues.apache.org/jira/browse/FLINK-31819
 Project: Flink
  Issue Type: Sub-task
  Components: Documentation
Affects Versions: 1.18.0
Reporter: Yuan Kui
 Fix For: 1.18.0


Add document for using watermark advanced functions in sql:

 



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

Re: [Discussion] - Take findify/flink-scala-api under Flink umbrella

[Chesnay Schepler]

> they require additional hop to serialize Scala objects

This doesn't necessarily mean that we need a Scala API, because a beefed 
up type extraction could also solve this.


> This single committer is now with us and ready to maintain it in open 
source. The best situation to be :-)


Have you considered maintaining the wrappers as part of flink-extended? 
https://github.com/flink-extended


On 17/04/2023 09:45, Alexey Novakov via user wrote:

Hi Günter, David,

Let me reply to you both in one email. First of all, thank you for 
engaging.


Günter:
- I fully agree that losing Scala API as officially supported in Flink 
would be very unfortunate. Future of Scala is interesting and will 
bring more benefits to Flink users.


Just to remind everyone, Flink Scala users can't only use Java API, 
they require additional hop to serialize Scala objects. This is one of 
the reasons why Flink still has Scala API (2.11) and why a few more 
3-rd party wrappers appeared to support newer versions of Scala when 
it became possible.


David:
Let me address your concerns.

1. It is indeed not a very active project. This is exactly the reason, 
I want to save https://github.com/findify/flink-scala-api from dying, 
because it is quite a good library to work with. Our Idea is to hit 
two targets: get a newer/official Scala API for Flink and do not let 
the 3rd-party (currently) library to sink. I use this library for 
daily work.
2. It works for Flink 1.15, support of Flink 1.16. requires just 
publishing a new version. I guess it is a one line change in the 
build.sbt file. Will see if more changes would be needed. I think the 
nature of changes will be similar like in StateFun, i.e. adopt to 
breaking changes of public methods and/or switch from deprecated 
methods to newer alternatives. Migrating further should not be a 
problem. Again, Scala API is supposed to be a thin wrapper on top of 
Java API, so that it is not labour-intensive
3. That single person left Findify (Roman) and they did not pay much 
attention to it. Actually, there is no other better alternative for 
Scala wrapper currently. This single committer is now with us and 
ready to maintain it in open source. The best situation to be :-)
4/5. Yes, same as #1. You can see some PRs in the queue from a Scala 
bot, but Findify does not merge them. The library is so small and 
covers most of the needs that additional changes are not yet 
identified/needed. I agree this could be a sign that few people are 
using it.


I have no idea which companies or users use this library. Is it 
really important to know? I just want to provide proper substitution 
to guarantee Scala is used further with Flink.
I know that the official Scala API was used or still used by world 
known enterprises.


Thank you for your suggestion. I have included dev ML in the original 
email. Let me try to come up with a more detailed plan.


Among maintainers you will get me, Roman (main dev of 
https://github.com/findify/flink-scala-api) and maybe Günter.


What is the downside or loss if we import this library into the Flink 
and in a few years nobody will use it? I guess we'll just depreciate it?
I just propose my free time to maintain that. As per Roman, required 
work to maintain the library is very simple.


Best regards,
Alexey

On Sun, Apr 16, 2023 at 11:46 AM David Morávek  wrote:

cc dev@f.a.o

On Sun, Apr 16, 2023 at 11:42 AM David Morávek 
wrote:

Hi Alexey,

I'm a bit skeptical because, looking at the project, I see a
couple of red flags:

- The project is inactive. The last release and commit are
both from the last May.
- The project has not been adapted for the last two Flink
versions, which signals a lack of users.
- All commits are by a single person, which could mean that
there is no community around the project.
- There was no external contribution (except the Scala bot).
- There is no fork of the project (except the Scala bot).

>  As I know, FIndify does not want or cannot maintain this
library.

Who are the users of the library? I'd assume Findify no longer
uses it if they're abandoning it.

> which would be similar to the StateFun

We're currently dealing with a lack of maintainers for
StateFun, so we should have a solid building ground around the
project to avoid the same issue.


I think there is value in having a modern Scala API, but we
should have a bigger plan to address the future of Flink Scala
APIs than importing an unmaintained library and calling it a
day. I suggest starting a thread on the dev ML and concluding
the overall plan first.

Best,
D.

On Sun, Apr 16, 2023 at 10:48 AM guenterh.lists
 wrote:

Hello Alexey

Thank you for your initiative and your suggestion!

I can only fully support 

Re: Need Help with Slack Invite Link

[Martijn Visser]

Hi Madhur,

Thanks for reaching out. The Slack invite link has been refreshed, you
should be able to join now via https://flink.apache.org/community/

Best regards,

Martijn

On Sat, Apr 15, 2023 at 11:03 PM Madhur Pyasi  wrote:

> Hello Flink Community,
> I am trying to use the slack invite to join the Flink workspace but the
> link is expired. Can somebody please share a new link or invite me (
> mdhr.py...@gmail.com) to the workspace?
>
> Wish you a fun weekend and look forward to learning from everyone here.
>
> -Madhur
>

Re: [Discussion] - Take findify/flink-scala-api under Flink umbrella

[Martijn Visser]

Hi Alexey,

> Taking into account my Scala experience for the last 8 years, I predict
these wrappers will eventually be abandoned, unless such a Scala library is
a part of some bigger community like ASF.

For the past couple of years, there have been no maintainers for Scala in
the Flink community. It was one of the reasons to deprecate the Scala APIs.
Given that the wrappers don't seem to have taken off outside of Flink, why
would moving them under the AS resolve this?

> Also, non-official Scala API will lead people to play safe and choose
Java API only, even if they did want that at the beginning.

Why would that be a problem? Wouldn't the fact that there are no
maintainers for the Scala wrappers actually indicate that Scala users are
actually fine with using the Java APIs, because else there would have been
improvements made towards the Scala wrappers?

Best regards,

Martijn

On Sun, Apr 16, 2023 at 11:47 AM David Morávek  wrote:

> cc dev@f.a.o
>
> On Sun, Apr 16, 2023 at 11:42 AM David Morávek  wrote:
>
> > Hi Alexey,
> >
> > I'm a bit skeptical because, looking at the project, I see a couple of
> red
> > flags:
> >
> > - The project is inactive. The last release and commit are both from the
> > last May.
> > - The project has not been adapted for the last two Flink versions, which
> > signals a lack of users.
> > - All commits are by a single person, which could mean that there is no
> > community around the project.
> > - There was no external contribution (except the Scala bot).
> > - There is no fork of the project (except the Scala bot).
> >
> > >  As I know, FIndify does not want or cannot maintain this library.
> >
> > Who are the users of the library? I'd assume Findify no longer uses it if
> > they're abandoning it.
> >
> > > which would be similar to the StateFun
> >
> > We're currently dealing with a lack of maintainers for StateFun, so we
> > should have a solid building ground around the project to avoid the same
> > issue.
> >
> >
> > I think there is value in having a modern Scala API, but we should have a
> > bigger plan to address the future of Flink Scala APIs than importing an
> > unmaintained library and calling it a day. I suggest starting a thread on
> > the dev ML and concluding the overall plan first.
> >
> > Best,
> > D.
> >
> > On Sun, Apr 16, 2023 at 10:48 AM guenterh.lists <
> guenterh.li...@bluewin.ch>
> > wrote:
> >
> >> Hello Alexey
> >>
> >> Thank you for your initiative and your suggestion!
> >>
> >> I can only fully support the following statements in your email:
> >>
> >>  >Taking into account my Scala experience for the last 8 years, I
> >> predict these wrappers will eventually be abandoned, unless such a Scala
> >> library is a part of some bigger community like ASF.
> >>  >Also, non-official Scala API will lead people to play safe and choose
> >> Java API only, even if they didn't want that at the beginning.
> >>
> >> Second sentence is my current state.
> >>
> >>  From my point of view it would be very unfortunate if the Flink project
> >> would lose the Scala API and thus the integration of concise, flexible
> >> and future-oriented language constructs of the Scala language (and
> >> further development of version 3).
> >>
> >> Documentation of the API is essential. I would be interested to support
> >> this efforts.
> >>
> >> Best wishes
> >>
> >> Günter
> >>
> >>
> >> On 13.04.23 15:39, Alexey Novakov via user wrote:
> >> > Hello Flink PMCs and Flink Scala Users,
> >> >
> >> > I would like to propose an idea to take the 3rd party Scala API
> >> > findify/flink-scala-api 
> >> > project into the Apache Flink organization.
> >> >
> >> > *Motivation *
> >> >
> >> > The Scala-free Flink idea was finally implemented by the 1.15 release
> >> and
> >> > allowed Flink users to bring their own Scala version and use it via
> the
> >> > Flink Java API. See blog-post here: Scala Free in One Fifteen
> >> > .
> Also,
> >> > existing Flink Scala API will be deprecated, because it is too hard to
> >> > upgrade it to Scala 2.13 or 3.
> >> >
> >> > Taking into account my Scala experience for the last 8 years, I
> predict
> >> > these wrappers will eventually be abandoned, unless such a Scala
> >> library is
> >> > a part of some bigger community like ASF.
> >> > Also, non-official Scala API will lead people to play safe and choose
> >> Java
> >> > API only, even if they did want that at the beginning.
> >> >
> >> > https://github.com/findify/flink-scala-api has already advanced and
> >> > implemented Scala support for 2.13 and 3 versions on top of Flink Java
> >> API.
> >> > As I know, FIndify does not want or does not have a capacity to
> maintain
> >> > this library. I propose to fork this great library and create a new
> >> Flink
> >> > project with its own version and build process (SBT, not Maven), which
> >> > would be similar to the StateFun or FlinkML 

[VOTE] FLIP-304: Pluggable Failure Enrichers

[Panagiotis Garefalakis]

Hello everyone,

I want to start the vote for FLIP-304: Pluggable Failure Enrichers [1]  --
discussed as part of [2].

FLIP-304 introduces a pluggable interface allowing users to add custom
logic and enrich failures with custom metadata labels.

The vote will last for at least 72 hours (Thursday, 20th of April 2023,
12:30 PST) unless there is an objection or insufficient votes.

[1]
https://cwiki.apache.org/confluence/display/FLINK/FLIP-304%3A+Pluggable+Failure+Enrichers
[2] https://lists.apache.org/thread/zs9n9p8d7tyvnq4yyxhc8zvq1k2c1hvs


Cheers,
Panagiotis