+1 for fixing it in these versions and doing quick releases. Looks good to me.
Best,
Jingsong
On Mon, Dec 13, 2021 at 2:18 PM Becket Qin wrote:
>
> +1. The solution sounds good to me. There have been a lot of inquiries
> about how to react to this.
>
> Thanks,
>
> Jiangjie (Becket) Qin
>
> On Mo
Hi Yingjie,
+1 for this FLIP. I'm pretty sure this will greatly improve the ease
of batch jobs.
Looks like "taskmanager.memory.framework.off-heap.batch-shuffle.size"
and "taskmanager.network.sort-shuffle.min-buffers" are related to
network memory and framework.off-heap.size.
My question is, wha
d be best if a rough table could be provided.
>
> I think this is a good suggestion, we can provide those suggestions in the
> document.
>
> Best,
> Yingjie
>
> Jingsong Li 于2021年12月14日周二 14:39写道：
>>
>> Hi Yingjie,
>>
>> +1 for this FLIP. I
Not found in
https://repo1.maven.org/maven2/org/apache/flink/flink-table-api-java/
I guess too many people sent versions, resulting in maven central
repository synchronization being slower.
Best,
Jingsong
On Fri, Dec 17, 2021 at 2:00 PM casel.chen wrote:
>
> I can NOT find flink 1.13.5 rel
flink subproject,
and we want to build the project under apache.
Best,
Jingsong
On Wed, Nov 24, 2021 at 8:10 PM Jingsong Li wrote:
>
> Hi Stephan,
>
> Thanks for your reply.
>
> Data never expires automatically.
>
> If there is a need for data retention, the user can choose o
;
> > That sounds promising! +1 from my side to continue development under
> > flink-dynamic-storage as a Flink subproject. I think having a more in-depth
> > interface will benefit everyone.
> >
> > Best regards,
> >
> > Martijn
> >
> > On Tu
Thanks!
Great job!
On Thu, Dec 30, 2021 at 11:10 PM Till Rohrmann wrote:
>
> This is really great news. Thanks a lot for all the effort Timo, Francesco
> and everyone else who was involved! I believe that this will make it a lot
> easier for our users to use any Scala version they want with Flin
nning to
> make this storage also available to DataStream API users? If not, I
> would also vote for `flink-managed-table` or better: `flink-table-store`
>
> Thanks,
> Timo
>
>
>
> On 29.12.21 07:58, Jingsong Li wrote:
> > Thanks Till for your suggestions.
> >
Hi everyone,
I'd like to start a vote for create a separate sub project for
FLIP-188 [1]: `flink-store`.
- If you agree with the name `flink-store`, please just +1
- If you have a better suggestion, please write your suggestion,
followed by a reply that can +1 to the name that has appeared
- If y
Hi everyone,
Vote for create a separate sub project for FLIP-188 thread is here:
https://lists.apache.org/thread/wzzhr27cvrh6w107bn464m1m1ycfll1z
Best,
Jingsong
On Fri, Jan 7, 2022 at 3:30 PM Jingsong Li wrote:
>
> Hi Timo,
>
> I think we can consider exposing to DataStream
> On Fri, Jan 7, 2022 at 9:14 AM Timo Walther wrote:
> >
> > > +1 for the separate project
> > >
> > > But maybe use `flink-storage` instead of `flink-store`?
> > >
> > > I'm not a native speaker but store is defined as "A place where i
https://github.com/facebook/rocksdb
[2] https://github.com/apache/hbase
Best,
Jingsong
On Fri, Jan 7, 2022 at 6:17 PM Jingsong Li wrote:
>
> Thanks all,
>
> Combining everyone's comments, I recommend using `flink-table-store`:
>
> ## table
> something to do with table storage (F
)?
>
> Best,
> D.
>
> On Fri, Jan 7, 2022 at 11:31 AM Jingsong Li wrote:
>
> > For more references on `store` and `storage`:
> >
> > For example,
> >
> > Rocksdb is a library that provides an embeddable, persistent key-value
> > store for fa
rate repository and release pipeline in
> the same way as
> > > >> > flink-statefun [1], flink-ml [2] and the coming
> flink-connectors [3].
> > > >> >
> > > >> > +1 for naming it as "flink-table-store" (I'm also ok
>
Thanks everyone for your voting.
If there are no objections, I'll close this vote and send a vote result mail:
- create a sub project named `flink-table-store`.
Best,
Jingsong
On Tue, Jan 11, 2022 at 2:51 PM Jingsong Li wrote:
>
> Hi Fabian,
>
> Thanks for your information.
+1 for dropping the MapR FS. Thanks for driving.
Best,
Jingsong
On Tue, Jan 11, 2022 at 5:22 PM Chang Li wrote:
>
> +1 for dropping the MapR FS.
>
> Till Rohrmann 于2022年1月5日周三 18:33写道：
>
> > +1 for dropping the MapR FS.
> >
> > Cheers,
> > Till
> >
> > On Wed, Jan 5, 2022 at 10:11 AM Martijn Vi
I am happy to announce that creating a separate sub project for
FLIP-188[1][2][3].
There are 12 approving votes, 10 of which are binding, 7 of which are
voting for flink-table-store:
* Timo Walther (binding)
* Till Rohrmann (binding)
* Konstantin Knauf(binding)
* David Moravek (binding)
* Yun Tang
Hi everyone,
We are creating flink-table-store[1] and we also find that flink-ml[2]
does not have clickable JIRA links, while flink-statefun[3] and
flink[4] do.
So I'm asking for PMC's help on how to make JIRA links clickable in github.
[1] https://github.com/apache/flink-table-store
[2] https:/
+1 Thanks Yingjie for driving.
Best,
Jingsong Lee
On Wed, Jan 12, 2022 at 3:16 PM 刘建刚 wrote:
>
> +1 for the proposal. In fact, we have used these params in our inner flink
> version for good performance.
>
> Yun Gao 于2022年1月12日周三 10:42写道：
>
> > +1 since it would highly improve the open-box expe
o
> Sent: Wednesday, January 12, 2022 14:59
> To: Jingsong Li ; dev
> Subject: Re: [DISCUSS] Seek help for making JIRA links clickable in github
>
> Currently it seems the issues of flink-statefun and flink-ml are
> also managed in the issues.apache.org ?
>
> Best,
> Yun
&g
+1 (non-binding)
- Verified checksums and signatures
- Build from source
- Start a standalone cluster, web is OK
- Start sql-client, everything looks good
Best,
Jingsong
On Wed, Jan 12, 2022 at 11:00 PM Till Rohrmann wrote:
>
> +1 (binding)
>
> - Verified checksums and signatures
> - Build from
Thanks Yun Tang,
flink-table-store and flink-ml can work now.
Best,
Jingsong
On Wed, Jan 12, 2022 at 4:41 PM Jingsong Li wrote:
>
> Hi Yun Gao,
> Yes, the issues of flink-statefun and flink-ml are also managed in the
> issues.apache.org. But the FLINK-XX in github is not clickable
+1 to merge the two modules.
Merging them I don't see any problem, not merging them I feel will
only increase the complexity of the dependencies.
Best,
Jingsong
On Wed, Jan 19, 2022 at 11:19 AM Jark Wu wrote:
>
> +1 to merge the two modules. This can avoid confusion when developers test
> conne
+1
Thanks Martijn for driving
Best,
Jingsong
On Thu, Jan 20, 2022 at 5:06 AM Thomas Weise wrote:
>
> +1 (binding)
>
> I think it would be a good idea to test the new infrastructure with a
> sample connector for the next release before moving existing connectors.
>
>
> On Wed, Jan 19, 2022 at 7
+1
Thanks for driving this Martijn!
Best,
Jingsong
On Thu, Jan 20, 2022 at 12:17 PM Qingsheng Ren wrote:
>
> +1 (non-binding)
>
> Thanks for driving this Martijn!
>
> Best,
>
> Qingsheng
>
> > On Jan 20, 2022, at 8:55 AM, heng du wrote:
> >
> > +1(non-binding)
> >
> > Thomas Weise 于2022年1月20日
Hi Jing,
Sorry for the late reply!
Is there a conclusion about naming here? (Maybe I missed something?)
Use USE_HASH or some other names. Slightly confusing in the FLIP.
And the problem of what to write inside the hint, as mentioned by lincoln.
I think maybe we can list the grammars of other di
'right_2', 'right_3') */ ？
It does not work, because the left input of the second join is not
'left_t' anymore. It is the output of the first join.
Best,
Jingsong
On Thu, Jan 20, 2022 at 2:33 PM Jingsong Li wrote:
>
> Hi Jing,
>
> Sorry for the late reply
;, 'right_1', 'right_2', 'right_3') */ ？
> >
> > It does not work, because the left input of the second join is not
> > 'left_t' anymore. It is the output of the first join.
> >
> > Good point.
> > As mentioned before, now SH
+1 (binding)
Thanks Jing!
Best,
Jingsong
On Mon, Jan 24, 2022 at 3:48 PM Jark Wu wrote:
>
> +1 (binding)
>
> Thanks Jing for driving this!
>
> Best,
> Jark
>
> On Thu, 20 Jan 2022 at 10:22, Jing Zhang wrote:
>
> > Hi community,
> >
> > I'd like to start a vote on FLIP-204: Introduce Hash Looku
+1 for extending the feature freeze.
Thanks Joe for driving.
Best,
Jingsong
On Wed, Jan 26, 2022 at 12:04 AM Martijn Visser wrote:
>
> Hi all,
>
> +1 for extending the feature freeze. We could use the time to try to wrap
> up some important SQL related features and improvements.
>
> Best regard
+1 to remove it.
Thanks for driving.
Best,
Jingsong
On Thu, Feb 17, 2022 at 8:44 PM Till Rohrmann wrote:
>
> +1 to remove it.
>
> Cheers,
> Till
>
> On Thu, Feb 17, 2022 at 1:42 PM Martijn Visser
> wrote:
>
> > +1 to remove it
> >
> > On Thu, 17 Feb 2022 at 13:34, Chesnay Schepler wrote:
> >
Congratulations!
Best,
Jingsong
On Thu, Feb 17, 2022 at 8:08 PM Jinzhong Li wrote:
>
> Congratulations!
>
>
> Best,
>
> Jinzhong
>
> On Wed, Feb 16, 2022 at 9:23 PM Robert Metzger wrote:
>
> > Hi all,
> >
> > I would like to formally announce a few new Flink PMC members on the dev@
> > list. Th
Congratulations!
Best,
Jingsong
On Fri, Feb 18, 2022 at 9:47 AM Zhipeng Zhang wrote:
>
> Thank you everyone for the warm welcome!
>
> Best,
> Zhipeng
>
> Jinzhong Li 于2022年2月17日周四 19:58写道：
>
> > Congratulations!
> >
> >
> > Best,
> >
> > Jinzhong
> >
> > Robert Metzger 于2022年2月16日周三 21:32写道：
>
Hi zoucao,
Thanks for your proposal. I believe this discussion will take us one
step further for iceberg/hudi integration.
## `MERGE` for streaming
I feel that `MERGE` is very good for stream computing. And, this is
where our Flink can have an advantage over other computation systems.
MERGE INT
Hi Till,
Good luck with the next chapter, and thanks for all of your efforts.
Best,
Jingsong
On Wed, Mar 2, 2022 at 2:57 PM Yufei Zhang wrote:
>
> Hi Till,
>
> Thank you Till, and good luck in your next chapter :)
>
> Cheers,
> Yufei
>
> On Mon, Feb 28, 2022 at 6:59 PM Till Rohrmann wrote:
>
>
+1.
Thanks for driving.
I wrote some scala code, the style of our flink's scala is messy. We
can do better.
Best,
Jingsong
On Wed, Mar 2, 2022 at 4:19 PM Yun Tang wrote:
>
> +1
>
> I also noticed that the project of scalafmt [1] is much more active than
> scalatyle [2], which has no release i
Congratulations Martijn!
Best,
Jingsong
On Fri, Mar 4, 2022 at 1:09 PM Yang Wang wrote:
>
> Congratulations Martijn!
>
> Best,
> Yang
>
> Yangze Guo 于2022年3月4日周五 11:33写道：
>
> > Congratulations!
> >
> > Best,
> > Yangze Guo
> >
> > On Fri, Mar 4, 2022 at 11:23 AM Lincoln Lee
> > wrote:
> > >
>
Thanks all for your discussions.
I'll share my opinion here:
1. Hive SQL and Hive-like SQL are the absolute mainstay of current
Batch ETL in China. Hive+Spark (HiveSQL-like)+Databricks also occupies
a large market worldwide.
- Unlike OLAP SQL (such as presto, which is ansi-sql rather than hive
s
Thanks for the proposal, yes, sql-client is too outdated. +1 for improving
it.
About "SET" and "RESET", Why not be "SET" and "UNSET"?
Best,
Jingsong
On Mon, Feb 1, 2021 at 2:46 PM Rui Li wrote:
> Thanks Shengkai for the update! The proposed changes look good to me.
>
> On Fri, Jan 29, 2021 at
+1 for the default "auto" to the "table.exec.time-function-evaluation".
>From the definition of these functions, in my opinion:
- Batch is the instant execution of all records, which is the meaning of
the word "BATCH", so there is only one time at query-start.
- Stream only executes a single recor
Thanks Rui for the proposal, I think this FLIP is required by many users,
and it is very good to traditional Hive users. I have some confusion:
# Version
Which Hive version do you want to choose? Maybe, Hive 3.X and Hive 2.X have
some differences?
# Hive Codes
Can you evaluate how much code we
Hi Etienne,
Thanks for your reporting.
There are indeed many problems. There is no doubt that we need to improve
our current format implementation.
But ParquetTableSource and ParquetInputFormat are legacy implementations
with legacy interfaces. We have introduced new interfaces for execution and
ang wrote:
> > Hi Jingsong,
> >
> > Thanks for pointing this out. Actually, I planned to work on changing
> > interfaces ParquetTableSource and ParquetInputFormat.
> > After refactoring the code, I may also help to fix the issue in
> > https://issues.apache.org/
+1
Thanks Leonard for driving this topic.
Best,
Jingsong
On Wed, Mar 3, 2021 at 4:44 PM Kurt Young wrote:
> +1 (binding)
>
> Best,
> Kurt
>
>
> On Wed, Mar 3, 2021 at 3:43 PM Timo Walther wrote:
>
> > +1 (binding)
> >
> > Regards,
> > Timo
> >
> > On 03.03.21 04:14, Jark Wu wrote:
> > > +1 (b
+1
Let's go straight to the right behavior. Drop the option for the wrong
behavior.
Best,
Jingsong
On Tue, Mar 9, 2021 at 4:29 PM Timo Walther wrote:
> Hi Leonard,
>
> I'm fine with dropping the old buggy behavior immediatly. Users can
> still implement a UDF with the old bavhior if needed. I
Thanks Danny for starting this discussion.
Big +1 for Implicit Type Coercion, in my opinion, it is very useful for
writing SQL conveniently.
I think there are two orthogonal things to discuss here:
1.[Matrix] Which types and which types can be implicitly converted.
2.[Strategies] In different cas
Hi,
Yes, as Danny said, it is very hard work...
A suggestion is that you can cherry-pick some bugfixs from the new Calcite
version to your own internal Calcite branch, if you just want to fix some
bugs.
Best,
Jingsong
On Thu, Mar 11, 2021 at 2:28 PM Danny Chan wrote:
> Hi Sheng ~
>
> It is a
> https://github.com/apache/flink/pull/14961
> >
> > If I have time, I'll also tackle the other parquet tickets that I
> > opened lately
> >
> > Best
> >
> > Etienne
> >
> > On 25/02/2021 08:34, Jingsong Li wrote:
> >> Hi Etienne,
&
11, 2021 at 3:41 PM Danny Chan wrote:
> Thanks for the feedback, Jingsong ~
>
> This design mainly follows the behaviors of PostgreSQL and SQL-SERVER,
> because their rules are more in line with the SQL standard.
>
> I have fixed the WIKI and add more details about the diff in i
+1 for simplifying.
We already have a thread of this topic:
http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/DISCUSS-Make-Temporal-Join-syntax-easier-to-use-td47296.html
FYI.
Best,
Jingsong
On Tue, Apr 20, 2021 at 4:55 PM Gyula Fóra wrote:
> Hi All!
>
> Playing around with the SQ
Congratulations Rui!
Best,
Jingsong
On Thu, Apr 22, 2021 at 11:52 AM Yun Gao
wrote:
> Congratulations Rui!
>
> Best,
> Yun
>
>
> --
> Sender:Nicholas Jiang
> Date:2021/04/22 11:26:05
> Recipient:
> Theme:Re: [ANNOUNCE] New Apache
Thanks Danny for starting the discussion.
+1 for this feature.
I like schema evolution.
A question:
Can we support multiple pipelines? For example, I have three source tables
and just one sink table.
So, I will write three CTAS:
- CTAS IF NOT EXISTS 1
- CTAS IF NOT EXISTS 2
- CTAS IF NOT EXIST
Hi santhosh,
1.I recommend you use the new source with ScanTablesource.
2.You can use `org.apache.flink.table.connector.source.SourceProvider` to
integrate to ScanTablesource. (Introduced in 1.12)
3.You can just implement a new source, this one can be used by both Flink
DataStream and Flink SQL.
urce abstraction? Is that
> what you're recommending?
>
> 2. Also, if we integrate the Kafkadynamicsource in Flink table with the
> KafkaSourceReader and KafkaSplitEnumerator abstractions, then would it be
> possible for us to contribute it back to the community?
>
> Tha
Thanks Yingjie for the great effort!
This is really helpful to Flink Batch users!
Best,
Jingsong
On Mon, Jun 7, 2021 at 10:11 AM Yingjie Cao wrote:
> Hi devs & users,
>
> The FLIP-148[1] has been released with Flink 1.13 and the final
> implementation has some differences compared with the ini
Congratulations, Xintong!
Best,
Jingsong
On Thu, Jun 17, 2021 at 10:26 AM Yun Tang wrote:
> Congratulations, Xintong!
>
> Best
> Yun Tang
>
> From: Leonard Xu
> Sent: Wednesday, June 16, 2021 21:05
> To: dev (dev@flink.apache.org)
> Subject: Re: [ANNOUNCE] New
Congratulations, Arvid!
Best,
Jingsong
On Thu, Jun 17, 2021 at 6:52 AM Matthias J. Sax wrote:
> Congrats!
>
> On 6/16/21 6:06 AM, Leonard Xu wrote:
> > Congratulations, Arvid!
> >
> >
> >> 在 2021年6月16日，20:08，Till Rohrmann 写道：
> >>
> >> Congratulations, Arvid!
> >>
> >> Cheers,
> >> Till
> >>
>
Hi, unsubscribe, please send to dev-unsubscr...@flink.apache.org instead of
dev@flink.apache.org
Best,
Jingsong
On Sat, Jun 19, 2021 at 9:51 PM 809590403 <809590...@qq.com.invalid> wrote:
> 退订
--
Best, Jingsong Lee
+1 to the release.
Thanks Dawid for driving this discussion.
I am willing to volunteer as the release manager too.
Best,
Jingsong
On Tue, Jun 22, 2021 at 9:58 AM godfrey he wrote:
> Thanks for driving this, Dawid. +1 to the release.
> I would also like to volunteer as the release manager for
+1 (binding)
Thanks for driving.
Best,
Jingsong
On Tue, Jun 22, 2021 at 12:07 AM Jark Wu wrote:
> +1 (binding)
>
> Best,
> Jark
>
> On Mon, 21 Jun 2021 at 22:51, Timo Walther wrote:
>
> > +1 (binding)
> >
> > Thanks for driving this.
> >
> > Regards,
> > Timo
> >
> > On 21.06.21 13:24, Ingo B
+1 to Xintong's proposal
I also have some concerns about unstable cases.
I think unstable cases can be divided into these types:
- Force majeure: For example, network timeout, sudden environmental
collapse, they are accidental and can always be solved by triggering azure
again. Committers should
Dear devs,
As discussed in [1], I would volunteer as the release manager for 1.12.5
and kick off the release process on next Wednesday (June 30th).
I went through 1.12.5 issues [2], all blockers have been fixed.
If you think there is any blocker in 1.12.5, please reply to this thread at
any time
;
> Best,
>
> Martijn
>
>
>
> On Thu, 24 Jun 2021 at 11:53, Jingsong Li wrote:
>
> > Dear devs,
> >
> > As discussed in [1], I would volunteer as the release manager for 1.12.5
> > and kick off the release process on next Wednesday (June 30th).
&
gt; > > > bumping/decreasing priorities of test instabilities (and bugs),
> > but
> > > > as
> > > > > > > individual committer I don't have the full picture. As I wrote
> > > > above, I
> > >
Hi everyone,
Please review and vote on the release candidate #1 for the version 1.12.5,
as follows:
[ ] +1, Approve the release
[ ] -1, Do not approve the release (please provide specific comments)
The complete staging area is available for your review, which includes:
* JIRA release notes [1],
*
+1 (non-binding)
- Verified checksums and signatures
- Built from sources
- run table example jobs
- web-ui looks good
- sql-client looks good
I think we should update the unresolved JIRAs in [1] to 1.13.3.
And we should check resolved JIRAs in [2], commits of some are not in the
1.13.2. We shou
Congratulations, Guowei!
Best,
Jingsong
On Wed, Jul 7, 2021 at 6:36 PM Arvid Heise wrote:
> Congratulations!
>
> On Wed, Jul 7, 2021 at 11:30 AM Till Rohrmann
> wrote:
>
> > Congratulations, Guowei!
> >
> > Cheers,
> > Till
> >
> > On Wed, Jul 7, 2021 at 9:41 AM Roman Khachatryan
> wrote:
> >
Congratulations, Yang!
Best,
Jingsong
On Wed, Jul 7, 2021 at 6:43 PM Arvid Heise wrote:
> Congratulations!
>
> On Wed, Jul 7, 2021 at 12:17 PM godfrey he wrote:
>
> > Congratulations, Yang!
> >
> > Best,
> > Godfrey
> >
> > Lijie Wang 于2021年7月7日周三 下午5:59写道：
> >
> > > Congratulations Yang!
> >
the result is expected
> > > > - started SQL Client, ran a simple query, the result is expected
> > > > - reviewed the web PR, left one minor name comment
> > > >
> > > > Best,
> > > > Leonard
> > > >
> > > > > 在 20
Congratulations Yuan!
Best,
Jingsong
On Thu, Jul 8, 2021 at 5:43 PM Arvid Heise wrote:
> Yay!
>
> On Thu, Jul 8, 2021 at 10:02 AM Jiayi Liao
> wrote:
>
> > Congratulations Yuan!
> >
> > Best,
> > Jiayi Liao
> >
> > On Thu, Jul 8, 2021 at 3:55 PM Roman Khachatryan
> wrote:
> >
> > > Congratula
> On Wed, Jul 7, 2021 at 1:29 PM Jingsong Li wrote:
>
> > Hi all,
> >
> > Thanks Xiongtong, Leonard, Yang, JING for the voting. Thanks Till for the
> > information.
> >
> > +1 for canceling this RC. That should also give us the chance to fix
> > FLI
BIG +1 for this. Thanks Stephan for starting this discussion.
Too many warnings in IDE and mvn build are frustrating. We can have the
opportunity to avoid the degradation of code quality.
Best,
Jingsong
On Thu, Jul 15, 2021 at 3:26 PM David Morávek
wrote:
> I know that sonar can report back by
Hi everyone,
Please review and vote on the release candidate #2 for the version 1.12.5,
as follows:
[ ] +1, Approve the release
[ ] -1, Do not approve the release (please provide specific comments)
The complete staging area is available for your review, which includes:
* JIRA release notes [1],
*
Thanks Chesnay!
Scala-free is really nice!
Best,
Jingsong
On Fri, Jul 16, 2021 at 2:01 PM Zhu Zhu wrote:
> Thanks Chesnay for this great work!
>
> Thanks,
> Zhu
>
> Steven Wu 于2021年7月16日周五 上午12:49写道：
>
> > This is awesome. Thank you, Chesney!
> >
> > On Wed, Jul 14, 2021 at 1:50 AM Yun Tang
+1 (binding)
Look forward to the production ready~
Best,
Jingsong
On Mon, Jul 19, 2021 at 3:25 PM Zhu Zhu wrote:
> +1 (binding)
>
> Thanks,
> Zhu
>
> XING JIN 于2021年7月19日周一 上午10:29写道：
>
> > +1 (non-binding)
> >
> > Best,
> > Jin
> >
> > Guowei Ma 于2021年7月19日周一 上午9:41写道：
> >
> > > +1(binding)
Hi everyone,
Please review and vote on the release candidate #3 for the version 1.12.5,
as follows:
[ ] +1, Approve the release
[ ] -1, Do not approve the release (please provide specific comments)
The complete staging area is available for your review, which includes:
* JIRA release notes [1],
*
I agree with Martijn.
My problem is just minor, which will make me a little disappointed.
Best,
Jingsong
On Tue, Jul 27, 2021 at 5:32 PM Martijn Visser
wrote:
> Hi,
>
> I personally would prefer to use "Normal" as a default priority because I
> think a lot of people's first reaction is that t
oint, everything is good.
> >> >
> >> > On Thu, Jul 29, 2021 at 2:34 PM Yun Tang wrote:
> >> >
> >> > > +1 (non-binding)
> >> > >
> >> > > Checked the signature.
> >> > >
> >> > > Revie
+1 (non-binding)
- Check if checksums and GPG files match the corresponding release files
- staging repository looks fine
- Start a local cluster (start-cluster.sh), logs fine
- Run sql-client and run a job, looks fine
I found an unexpected log in sql-client:
"Searching for
'/Users/lijingsong/Dow
+1 (non-binding)
- Verified checksums and signatures
- Verified local cluster
- Verified sql-client and run a job
Best,
Jingsong
On Thu, Jul 29, 2021 at 9:26 PM Robert Metzger wrote:
> Thanks a lot for creating the release candidate!
>
> +1 (binding)
>
> Checks:
> - manually checked the diff [
Dear all,
I'm happy to announce that we have unanimously approved the release of
1.12.5.
There are 10 approving votes, 4 of which are binding:
* Yun Tang
* Zakelly Lan
* Xingbo Huang
* Robert Metzger (binding)
* Godfrey He
* Jark Wu (binding)
* Leonard Xu
* Dian F
Thanks liwei for the contribution.
I will take a look and help to merge~
Best,
Jingsong
On Thu, Aug 5, 2021 at 6:24 PM Till Rohrmann wrote:
> Hi Liwei,
>
> Thanks for helping the community. At the moment most of the committers are
> busy with finishing their work for the upcoming feature freez
Hi bowen,
Thanks for starting this discussion.
I think you can describe your design/implementation in detail. I understand
local_ref can help us optimize, but it still needs many details, such as
how to reuse function results in codegen. We need a cleaner solution to
avoid polluting our CodeGen c
Thanks Yun Tang and everyone!
Best,
Jingsong
On Tue, Aug 10, 2021 at 9:37 AM Xintong Song wrote:
> Thanks Yun and everyone~!
>
> Thank you~
>
> Xintong Song
>
>
>
> On Mon, Aug 9, 2021 at 10:14 PM Till Rohrmann
> wrote:
>
> > Thanks Yun Tang for being our release manager and the great work! Al
Hi David,
According to my understanding, all classes that are not marked are
internal classes, and they have no guarantee of compatibility.
You'd better copy them for your own use.
(Implementing pre-aggregation via the DataStream API using
MapBundleFunctions is a good idea)
Best,
Jingsong
On F
Hi,
I remember the projection only works with SupportsProjectionPushDown.
You can take a look at
`PushProjectIntoTableSourceScanRuleTest.testNestProjectWithMetadata`.
Will applyReadableMetadata again in the PushProjectIntoTableSourceScanRule.
But there may be bug in
PushProjectIntoTableSourceSc
Hi all,
Since Flink 1.14 is already code freeze, we'd like to merge
FLINK-23755 [1]. PR is [2]
We think FLINK-23755 is not a new feature, but it is a behavior
changer and an usability improvement. It's disappointing to wait for
one more release for users.
What do you think?
[1]https://issues.ap
Jingsong
On Tue, Aug 24, 2021 at 4:48 PM Jingsong Li wrote:
>
> Hi all,
>
> Since Flink 1.14 is already code freeze, we'd like to merge
> FLINK-23755 [1]. PR is [2]
>
> We think FLINK-23755 is not a new feature, but it is a behavior
> changer and an usability improve
Hi Xingcan,
As a workaround, can we convert large decimal to varchar?
If Flink SQL wants to support large decimal, we should investigate
other big data and databases. As Jark said, this needs a lot of work.
Best,
Jingsong Lee
On Tue, Aug 31, 2021 at 11:16 AM Jark Wu wrote:
>
> Hi Xingcan, Timo
Hi all,
It was a wonderful discussion.
I think it can be made clear that PublicEvolving must not provide
cross version compatibility, which means that once the connector wants
to use new features, it must not be cross version compatible.
However, the connector must maintain multiple versions. Ma
Thanks! "only running the jobs that actually failed" is very useful.
A small problem may have been solved. After a commit, we cannot rerun
the failed test before the commit. (The test triggered by commit has
not finished yet. The test triggered again should run the full cases)
Best,
Jingsong
On
Hi all,
Kurt and I propose to introduce built-in storage support for dynamic
table, a truly unified changelog & table representation, from Flink
SQL’s perspective. We believe this kind of storage will improve the
usability a lot.
We want to highlight some characteristics about this storage:
- It
hus tables
> > don't necessarily need to contain such an option already today. How will
> > this interact / work with catalogs? I think there are more points regarding
> > interaction with catalogs, e.g. if tables are dropped externally rather
> > than through Flink S
Thanks, Chesnay & Martijn
1.13.3 really solves many problems.
Best,
Jingsong
On Thu, Oct 21, 2021 at 6:46 PM Konstantin Knauf wrote:
>
> Thank you, Chesnay & Martijn, for managing this release!
>
> On Thu, Oct 21, 2021 at 10:29 AM Chesnay Schepler
> wrote:
>
> > The Apache Flink community is v
sers should be aware of
> creating a Flink-managed table.
>
> We also need to consider the upgrade path here: if a catalog exposes tables
> without 'connector' options today, we need to make sure that once this FLIP
> is implemented no errors are thrown because codepaths ass
ink suffers from a lot is inconsistencies across APIs. I think
> it is important that we support features on all major APIs, i.e. including
> Table API.
> For example for creating a BDT this would mean e.g. adding something like
> #forManaged(…) to TableDescriptor.
>
>
> Best
>
PM Jingsong Li wrote:
>
> Hi Ingo,
>
> Really appreciate your feedback.
>
> #1. The reason why we insist on using no "connector" option is that we
> want to bring the following design to users:
> - With the "connector" option, it is a mapping, unmanag
> > Kurt
> >
> >
> > On Fri, Oct 29, 2021 at 11:53 PM Till Rohrmann
> > wrote:
> >
> > > Hi Jingsong,
> > >
> > > Thanks for creating this FLIP. I don't have a lot to add because I am not
> > > very familiar with the SQL com
Hi Fabian,
Thanks for drafting the FLIP!
## Few thoughts of user requirements
1.compact files from multiple checkpoints
This is what users need very much.
2.The compaction block the checkpointing
- Some scenarios are required. For example, the user expects the
output data to be consistent wit
+1 (non-binding)
This greatly enhances the ease of use of batch jobs. (Parallelism
setting is really a challenge)
(non-binding: I'm not familiar with runtime, just a general understanding)
Best,
Jingsong
On Tue, Nov 9, 2021 at 3:48 PM David Morávek wrote:
>
> Thanks for the FLIP, this is going
401 - 500 of 613 matches
Mail list logo
