+1(non-binding)
Best,
CaoZhen
Replied Message
| From | weijie guo |
| Date | 5/20/2025 13:42 |
| To | |
| Subject | Re: [VOTE] FLIP-486: Introduce a new DeltaJoin |
+1(binding)
Best regards,
Weijie
xiangyu feng 于2025年5月20日周二 12:37写道：
+1(non-binding)
Best,
Xiangyu
Ron Liu 于2
+1(binding)
Best regards,
Weijie
xiangyu feng 于2025年5月20日周二 12:37写道：
> +1(non-binding)
>
> Best,
> Xiangyu
>
> Ron Liu 于2025年5月20日 周二09:51写道：
>
> > +1(binding)
> >
> > Best,
> > Ron
> >
> > Xuyang 于2025年5月20日周二 09:42写道：
> >
> > > Hi, devs.
> > > I'd like to start a vote on FLIP-486: Introduc
+1(non-binding)
Best,
Xiangyu
Ron Liu 于2025年5月20日 周二09:51写道：
> +1(binding)
>
> Best,
> Ron
>
> Xuyang 于2025年5月20日周二 09:42写道：
>
> > Hi, devs.
> > I'd like to start a vote on FLIP-486: Introduce a new DeltaJoin[1], which
> > has been discussed in this thread[2].
> > The vote will be open for at l
+1 for it, a great feature.
Best,
Ron
Lu Niu 于2025年5月20日周二 06:27写道：
> Hi Flink Developers,
>
> We’ve noticed that storage partition join is currently not supported in
> Flink. For reference, Spark has supported this feature for some time (see:
> https://issues.apache.org/jira/browse/SPARK-37375
+1(binding)
Best,
Ron
Xuyang 于2025年5月20日周二 09:42写道：
> Hi, devs.
> I'd like to start a vote on FLIP-486: Introduce a new DeltaJoin[1], which
> has been discussed in this thread[2].
> The vote will be open for at least 72 hours unless there is an objection
> or not enough votes.
>
>
> [1]
> https
Hi, devs.
I'd like to start a vote on FLIP-486: Introduce a new DeltaJoin[1], which has
been discussed in this thread[2].
The vote will be open for at least 72 hours unless there is an objection or not
enough votes.
[1]
https://cwiki.apache.org/confluence/display/FLINK/FLIP-486%3A+Introduce+A
Alan Sheinberg created FLINK-37817:
--
Summary: Add Bundled Aggregate API and operator for group by
Key: FLINK-37817
URL: https://issues.apache.org/jira/browse/FLINK-37817
Project: Flink
Issue
Alan Sheinberg created FLINK-37816:
--
Summary: FLIP-491: BundledAggregateFunction for batched aggregation
Key: FLINK-37816
URL: https://issues.apache.org/jira/browse/FLINK-37816
Project: Flink
Hi Flink Developers,
We’ve noticed that storage partition join is currently not supported in
Flink. For reference, Spark has supported this feature for some time (see:
https://issues.apache.org/jira/browse/SPARK-37375 ). Our user case is to
support storage partition join on iceberg tables in flink
tooptoop4 created FLINK-37815:
-
Summary: JDBC lookup cache - dont query db even if missing
Key: FLINK-37815
URL: https://issues.apache.org/jira/browse/FLINK-37815
Project: Flink
Issue Type: New F
Thanks everyone for the discussion!
I'm going to start a voting thread soon unless there are other suggestions
or objections.
Regards,
Roman
On Sat, May 17, 2025 at 2:01 PM Roman Khachatryan wrote:
> Thanks Chesnay, I like your idea of returning 403 for non-white-listed
> options. Updated the
Hi David,
The following stack trace is generated on the jobmanager:
2025-05-19 17:54:34,474 INFO
org.apache.flink.runtime.executiongraph.ExecutionGraph [] - Source:
inputTbl[1] -> (Calc[2] -> ConstraintEnforcer[3] -> outputTbl[3]: Writer ->
outputTbl[3]: Committer, Calc[4] -> Constrain
Hi Fred,
I see. It looks like this check was added in
https://issues.apache.org/jira/browse/FLINK-37282
Do you have a stack trace for the exception – this could show how you got to
this code in the at least once case?
By copy Arvid: any thoughts on this?
Kind regards, David.
From: Teunisse
Gustavo de Morais created FLINK-37814:
-
Summary: FLIP-516: Adjust FlinkJoinToMultiJoinRule for Multi Join
Operator
Key: FLINK-37814
URL: https://issues.apache.org/jira/browse/FLINK-37814
Project:
Hi David,
Depending on the flink version we use a different Kafka connector.
*
flink:2.0.0 -> flink-connector-kafka:4.0.0-2.0
*
flink:1.20.1 -> flink-connector-kafka:3.4.0-1.20
*
flink:1.19.2 -> flink-connector-kafka:3.3.0-1.19
We are using the default for delivery-guarantee (at-least-once
Hi,
In addition to the proposal below , another alternative would be to create a
Github app using probot [1] – similar to boring-cyborg [2] that we already use.
I am going to prototype this approach, as it seems simpler than the shared git
action cache approach,
Feedback welcome,
Kind regards,
Hi,
I had a quick look at this. What version of the Flink Kafka connector are you
running?
I looked through recent commits in the Kafka connector and see
https://github.com/apache/flink-connector-kafka/commit/7c112abe8bf78e0cd8a310aaa65b57f6a70ad30a
for PR https://github.com/apache/flink-connecto
Hi,
As most of the regulars are travelling this week, I have cancelled this week’s
Community Health Initiative workgroup [1] call.
The next meeting will be on:
29th of May 5PM GMT 2025. Access on this link [2].
Kind regards, David.
[1]
https://cwiki.apache.org/confluence/display/FLINK/Comm
Baozhu Zhao created FLINK-37813:
---
Summary: JobManager failover during allocation slots causes
ResourceManager to release unwanted TaskManager failure
Key: FLINK-37813
URL: https://issues.apache.org/jira/browse/FLINK
Hi,
I have been playing with git actions for FLIP-518 and have found the following.
pull_request_review
Github actions will always get a read only Github tokens when driven from a
fork (our PRs come from forks) so cannot add labels or look at the collaborator
role to see if they are a committer.
Hi everyone,
I'm encountering an issue with Flink 2.0 when using the Table API. In previous
versions (1.19/1.20), I was able to create a Flink job with the following setup:
*
One Kafka topic-based input table
*
One Kafka topic-based output table
*
One statement set with two insert statemen
Hello Fu, I have tried "unalign checkpoint" before I ask, but it seems to
effect only in "AT_LEAST_ONCE" mode.
in my thought, "AT_LEAST_ONCE" mode makes slower checkpointing right?
And I restart the job still, the first checkpoint is slower indeed.
At 2025-05-16 13:52:44, "Di
22 matches
Mail list logo
