Hey!
I may have missed this in the FLIP but did not find it spelled out
explicitly.
Can the user use the entire record processing context in their async
execution?
In other words can they access all functionality from the callback? For
example can they simply reference the keyed context and
LvYanquan created FLINK-34638:
-
Summary: Support default value of table column.
Key: FLINK-34638
URL: https://issues.apache.org/jira/browse/FLINK-34638
Project: Flink
Issue Type: Improvement
发送一封不包含任何内容或主题的邮件到 listname-subscr...@flink.apache.org（替换 listname 为 dev,
user, user-zh 等等）来取消订阅。
如：dev-unsubscr...@flink.apache.org 取消订阅来自 dev@flink.apache.org 邮件列表的邮件。
邮件列表的订阅管理，可以参考[1]。
Best,
Jiabao
[1] https://flink.apache.org/zh/what-is-flink/community/
ss zz 于2024年3月11日周一 13:20写道：
>
退订
退订
Hi, Jeyhun.
Thanks for the reply.
Is this argument true for all workloads? Or does this argument also hold
for workloads with many small files, which is quite a common case [1] ?
Yes, I think so. The overhead should still be considered negligible,
particularly in comparison to remote I/O, and
Hi Jing,
Thanks for your thoughtful feedback!
> does it mean that there will be three mails for Read, Update, and Output ?
With this example, there are two mails. The Read is processed by
`mailboxDefaultAction`[1], and the Update and Output are encapsulated
as mail.
> does it make sense to
Sergey Nuyanzin created FLINK-34637:
---
Summary: Migrate JoinConditionEqualityTransferRule
Key: FLINK-34637
URL: https://issues.apache.org/jira/browse/FLINK-34637
Project: Flink
Issue Type:
Hi devs,
I’d like to start a discussion on FLIP-434: Support optimizations for
pre-partitioned data sources [1].
The FLIP introduces taking advantage of pre-partitioned data sources for
SQL/Table API (it is already supported as experimental feature in
DataStream API [2]).
Please find more
Hi Martijn,
Thanks for your comment. I created a quick prototype to make sure that the
proposed hypothesis works. So, it still is a quick implementation.
On my local setup all tests pass, but I might need to spend some time (once
VOTE thread passes probably) to clean it and submit a PR.
Each
Hi Hangxiang,
Thanks for the proposal. +1 for it.
I have a few comments.
Proposal 2 has additional JNI overhead, but the overhead is relatively
> negligible when weighed against the latency of remote I/O.
- Is this argument true for all workloads? Or does this argument also hold
for workloads
Hi Jinzhong,
Thanks for driving this topic and sorry for just joining the discussion
now. I replied in your discussion thread. Would you like to take a look
and let's keep the discussion there? I will come back to this thread and
vote once the discussion is done. Thanks!
Best regards,
Jing
On
Hi Jinzhong,
Sorry for the late reply. The key guideline of adding visibility annotation
is whether the interface/class is a customer-facing API. I was wondering if
SingleStateIterator and RocksDBRestoreOperation are exposed to users even
if they are interfaces, i.e. users can use their own
Hi Ferenc,
Thanks for the proposal! +1 for it!
Similar to what Leonard mentioned. I would suggest:
1. Use the "release" to define the release version of the Kudu connector
itself.
2. Optionally, add one more row underneath to describe which Flink versions
this release will be compatible with,
Hi Yanfei,
Thanks for your proposal! The FLIP contains a lot of great new ideas. I'd
like to ask some questions to make sure we are on the same page.
> For the asynchronous interface, Record A should run with Read, Update and
Output, while Record B should stay at the Blocking buffer.
1. With
Hi Ferenc, +1 for this FLIP.
Ferenc Csaky 于2024年3月9日周六 01:49写道：
> Thank you Jeyhun, Leonard, and Hang for your comments! Let me
> address them from earliest to latest.
>
> > How do you plan the review process in this case (e.g. incremental
> over existing codebase or cumulative all at once) ?
>
Hi Zakelly,
Thanks for your proposal. The FLIP looks in good shape. +1 for it! I'd like
to ask some questions to understand your thoughts more precisely.
1. StateFuture is a new interface. At first glance, it should
be @Experimental. But according to our API Arch rule[1], it should be at
least
Vincent Woo created FLINK-34636:
---
Summary: Requesting exclusive buffers timeout causes repeated
restarts and cannot be automatically recovered
Key: FLINK-34636
URL: https://issues.apache.org/jira/browse/FLINK-34636
18 matches
Mail list logo
