Re: 回复：Re:[DISCUSS] FLIP-214 Support Advanced Function DDL

Hi Ron, thanks for opening this discussion and proposing a FLIP. This feature has been requested multiple times before and it is definitely something that the Flink community wants. However, we have to ensure that this change fits into the overall architecture and doesn't break core assumptio

Re: [DISCUSS] Flink SQL Syntax for Query/Savepoint Management

g one. Please give me the permission if possible. My Confluence user name is `paulin3280`, and the full name is `Paul Lam`. I'm also copying in @Timo Walther and @Jark Wu for their opinion on this. Looking forward to your opinions @Timo @Jark :) Best, Paul Lam 2022年4月1日 18:10，Martijn Visse

Re: [DISCUSS] assign SQL Table properties from environment variables

Hi Fred, thanks for starting this discussion. I totally agree that this an issue that the community should solve. It popped up before and is still unsolved today. Great that you offer your help here. So let's clarify the implementation details. 1) Global vs. Local solution Is this a DDL-onl

Re: [ANNOUNCE] New scalafmt formatter has been merged

Thanks for the great work Francesco! This will improve the contributor productivity a lot and ease reviews. This change was long overdue. Regards, Timo Am 12.04.22 um 17:21 schrieb Francesco Guardiani: Hi all, The new scalafmt formatter has been merged. From now on, just using mvn spotless:a

Re: [VOTE] Release 1.15.0, release candidate #3

-1 We found a regression in one of the core SQL operations (i.e. CAST string<->binary) [1]. It would be better to fix this immediately to avoid confusion. Also, we can use the time to fix another small regression where a PR is also almost ready [2]. Both should be merged in the next hours.

Re: [DISCUSS] Maintain a Calcite repository for Flink to accelerate the development for Flink SQL features

Hi Godfrey, I'm also strictly against maintaining a Calcite fork. We had similar discussions during the merge of the Blink code base in the past and I'm happy that we could prevent a fork until today. Let me elaborate a bit on my strict opinion here: 1) Calcite does not offer bugfix releases

[DISCUSS] Backport scalafmt to 1.15 branch

Hi everyone, The 1.15 release is almost out. We should still discuss whether we want to backport scalafmt to the release-1.15 branch. Currently, it is quite cumbersome to backport fixes in the table planner. It seems scalafmt has stabilized in master. Are you ok with backporting the changes

Re: [ANNOUNCE] Apache Flink 1.15.0 released

It took a bit longer than usual. But I'm sure the users will love this release. Big thanks to the release managers! Timo Am 05.05.22 um 10:45 schrieb Yuan Mei: Great! Thanks, Yun Gao, Till, and Joe for driving the release, and thanks to everyone for making this release happen! Best Yuan On

[REMINDER] Final Call for Presentations for Flink Forward San Francisco 2022

Hi everyone, I would like to send out a final reminder. We have already received some great submissions for FlinkForward San Francisco 2022. Nevertheless, we decided to extend the deadline by another week to give people a second chance to work on their abstracts and presentation ideas. This

Re: [Discuss] Creating an Apache Flink slack workspace

I also think that a real-time channel is long overdue. The Flink community in China has shown that such a platform can be useful for improving the collaboration within the community. The DingTalk channel of 10k+ users collectively helping each other is great to see. It could also reduce the bur

Re: [DISCUSS] FLIP-91: Support SQL Client Gateway

Hi Shengkai, sorry for jumping in so late into the discussion. There was a lot going on in the last 3 weeks. This FLIP is very important and it is great that you tackle this topic which is planned since we started with the SQL Client. The ML discussion is already quite long. It would be great

Re: [DISCUSS] FLIP-91: Support SQL Client Gateway

Hi Shengkai, Hi Jark, thanks for the additional explanation and the update of the FLIP. This will help us in the future for documenting our decisions. The arguments why to include the Gateway into the main repo make a lot of sense to me. Esp. also because both CLI and gateway need some parsing

Re: [VOTE] Creating an Apache Flink slack workspace

+1 (binding) Thanks, Timo On 17.05.22 20:44, Gyula Fóra wrote: +1 (binding) On Tue, 17 May 2022 at 19:52, Yufei Zhang wrote: +1 (nonbinding) On Tue, May 17, 2022 at 5:29 PM Márton Balassi wrote: +1 (binding) On Tue, May 17, 2022 at 11:00 AM Jingsong Li wrote: Thank Xintong for driv

Re: [DISCUSS] FLIP-91: Support SQL Client Gateway

ironment#executeSql. That is, the input of the statement is a single statement rather than the script. Considering the API in the FLIP is not as same as the initialization in the CLI, I think we can use the configure_session? What do you think, Timo? Best, Shengkai Timo Walther 于2022年5月16日周一

Re: [VOTE] FLIP-229: Introduces Join Hint for Flink SQL Batch Job

+1 (binding) Thanks for driving this! Timo On 19.05.22 08:44, Leonard Xu wrote: Thanks Xuyang for driving this work. +1(binding) Best, Leonard 2022年5月19日 上午10:46，Yun Tang 写道： Thanks for driving, +1 (binding) Best Yun Tang From: Jark Wu Sent: Wednes

Re: [VOTE] FLIP-91: Support SQL Gateway

+1 (binding) Thanks, Timo On 23.05.22 03:53, Jingsong Li wrote: +1 Best, Jingsong On Sat, May 21, 2022 at 12:23 AM Shqiprim Bunjaku wrote: +1 (non-binding) Best, Shqiprim Bunjaku On Fri, May 20, 2022 at 5:56 PM Yufei Zhang wrote: +1 (non-binding) Best, Yufei Zhang On Fri, May 20, 20

Re: [VOTE] FLIP-188 Introduce Built-in Dynamic Table Storage

song On Sat, Nov 13, 2021 at 1:27 AM Timo Walther wrote: Hi everyone, even though the DISCUSS thread was open for 2 weeks. I have the feeling that the VOTE was initiated to quickly. At least a final "I will start the vote soon. Last call for comments." would have been nice. I a

Re: [DISCUSS] FLIP-190: Support Version Upgrades for Table API & SQL Programs

Hi everyone, thanks for the feedback so far. Let me answer each email indvidually. I will start with a response to Ingo's feedback: > Will the JSON plan's schema be considered an API? No, not in the first version. This is explicitly mentioned in the `General JSON Plan Assumptions`. I tried to

Re: [DISCUSS] FLIP-190: Support Version Upgrades for Table API & SQL Programs

ABLE IF NOT EXISTS is not executed again. So a mismatch could also occur there. Regards, Timo On 30.11.21 14:17, Timo Walther wrote: Hi everyone, thanks for the feedback so far. Let me answer each email indvidually. I will start with a response to Ingo's feedback: > Will the JS

Re: [DISCUSS] FLIP-190: Support Version Upgrades for Table API & SQL Programs

an file. This is already considered in the COMPILE PLAN ... FROM ... even though this is future work. Also savepoint migration. Thanks for all the feedback! Timo On 30.11.21 14:28, Timo Walther wrote: Response to Wenlongs's feedback: > I would prefer not to provide such a short

Re: [DISCUSS] FLIP-190: Support Version Upgrades for Table API & SQL Programs

the ExecNode from the code base? Please check the section 10.1.1 again. I added a more complex example. Thanks, Timo On 01.12.21 16:29, Timo Walther wrote: Response to Francesco's feedback: > *Proposed changes #6*: Other than defining this rule of thumb, we must also make sure

Re: [DISCUSS] FLIP-190: Support Version Upgrades for Table API & SQL Programs

from the SQL statement but from the old plan. I have added an example in section 10.1.1. In general, both persisted entities "plan" and "savepoint" can evolve independently from each other. Thanks, Timo On 02.12.21 15:10, Timo Walther wrote: Response to Godfrey's feedback:

Re: [DISCUSS] FLIP-190: Support Version Upgrades for Table API & SQL Programs

Flink 1.11 to 1.12, right? Cheers, Till On Thu, Dec 2, 2021 at 3:39 PM Timo Walther wrote: Response to Till's feedback: > compiled plan won't be changed after being written initially This is not entirely correct. We give guarantees for keeping the query up and running. We reserve

Re: [DISCUSS] FLIP-190: Support Version Upgrades for Table API & SQL Programs

running EXECUTE (or just the statement itself) without calling COMPILE should be sufficient. The file can also manually be deleted if necessary. What do you think? Regards, Timo On 02.12.21 16:09, Timo Walther wrote: Hi Till, Yes, you might have to. But not a new plan from the SQL query

Re: [DISCUSS] FLIP-197: API stability graduation process

Hi Till, thanks for starting this discussion. I think this topic should have been discussed way earlier. I have two questions: 1) It might be an implementation detail but where do you expect this `FlinkVersion` to be located? This is actually a quite important class that also needs to be mad

Re: [DISCUSS] FLIP-190: Support Version Upgrades for Table API & SQL Programs

he state is compatible with the state generated by the given version node) ? The names also indicate that only one version value can be set. WDYT? Best, Godfrey Timo Walther 于2021年12月2日周四 下午11:42写道： Response to Marios's feedback: > there should be some good logging in place w

Re: [VOTE] Deprecate Java 8 support

+1 (binding) Thanks, Timo On 06.12.21 17:28, David Morávek wrote: +1 (non-binding) On Mon, Dec 6, 2021 at 4:55 PM Ingo Bürk wrote: +1 (non-binding) Ingo On Mon, Dec 6, 2021 at 4:44 PM Chesnay Schepler wrote: Hello, after recent discussions on the dev

Re: [DISCUSS] FLIP-190: Support Version Upgrades for Table API & SQL Programs

old version state layout and clean up the deprecated code. We still need to update the version, so that we can verify that we are compatible with the plan after the first change, but not compatible with the plan earlier. Best, Wenlong On Mon, 6 Dec 2021 at 21:27, Timo Walther wrote: Hi Godf

Re: [DISCUSS] FLIP-190: Support Version Upgrades for Table API & SQL Programs

compatible. The error message may be not so friendly if we just throw deserialization failure. On Tue, 7 Dec 2021 at 16:49, Timo Walther wrote: Hi Wenlong, > First, we add a newStateLayout because of some improvement in state, in > order to keep compatibility we may still keep the old s

Re: [DISCUSS] FLIP-190: Support Version Upgrades for Table API & SQL Programs

and `supportedSavepointFormat` and version need to be changed. I think we need a detail explanation about the annotations change story in the java doc of `ExecNodeMetadata` class for all developers (esp. those unfamiliar with this part). Best, Godfrey Timo Walther 于2021年12月8日周三 下午4:57写道： Hi Wenlon

Re: [DISCUSS] Shall casting functions return null or throw exceptions for invalid input

that the operation might fail and provide a result different from the cast result. On Fri, Nov 19, 2021 at 4:00 AM Kurt Young wrote: Hi Timo, Regarding CAST, I think no one denies the standard behavior which should raise errors when failed. The only question is how do we solve it, gi

Re: [DISCUSS] FLIP-190: Support Version Upgrades for Table API & SQL Programs

e JSON plan flinkVersion changes to 1.17.* Best, Wenlong On Thu, 9 Dec 2021 at 18:36, Timo Walther wrote: Hi Jing and Godfrey, I had another iteration over the document. There are two major changes: 1. Supported Flink Upgrade Versions I got the feedback via various channels that a st

Re: [DISCUSS] FLIP-190: Support Version Upgrades for Table API & SQL Programs

the explanation. I totally agree with what you said. My actual question is: Will the version of an exec node be serialised in the Json Plan? In my understanding, it is not in the former design. If it is yes, my question is solved already. Best, Wenlong On Fri, 10 Dec 2021 at 18:15, Timo Walther

Re: [DISCUSS] FLIP-200: Support Multiple Rule and Dynamic Rule Changing (Flink CEP)

Hi all, I don't think it is easy to integrate this kind of functionality in SQL/Table API. The CEP library can be more powerful than MATCH_RECOGNIZE. I haven't taken a look at the FLIP yet. But I would be fine to leave Table API/SQL up for future work and a separate FLIP. Regards, Timo On

Re: [DISCUSS] FLIP-190: Support Version Upgrades for Table API & SQL Programs

Timo, +1 for the improvement. Best, Godfrey Timo Walther 于2021年12月10日周五 20:37写道： Hi Wenlong, yes it will. Sorry for the confusion. This is a logical consequence of the assumption: The JSON plan contains no implementation details (i.e. no classes) and is fully declarative. I will add a remark

[VOTE] FLIP-190: Support Version Upgrades for Table API & SQL Programs

Hi everyone, I'd like to start a vote on FLIP-190: Support Version Upgrades for Table API & SQL Programs [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/x/K

[RESULT][VOTE] FLIP-190: Support Version Upgrades for Table API & SQL Programs

zin wrote: +1 (non-binding) On Wed, Dec 15, 2021 at 11:22 AM godfrey he wrote: +1 (binding) Best, Godfrey Ingo Bürk 于2021年12月15日周三 16:19写道： +1 (binding) Thanks for driving this much needed feature! On 14.12.21 17:45, Timo Walther wrote: Hi everyone, I'd like to start a vote on FLI

Re: [DISCUSS] FLIP-188: Introduce Built-in Dynamic Table Storage

+1 for a separate repository. And also +1 for finding a good name. `flink-warehouse` would be definitely a good marketing name but I agree that we should not start marketing for code bases. Are we planning to make this storage also available to DataStream API users? If not, I would also vote f

[NOTICE] Table API is now Scala-free by introducing a flink-table-planner-loader

Hi everyone, The new module flink-table-planner-loader replaces flink-table-planner_2.12 and avoids the need for a specific Scala version in downstream projects. It is included in the Flink distribution under /lib. For backwards compatibility, users can still swap it with flink-table-planner_

Re: [VOTE] Create a separate sub project for FLIP-188: flink-store

+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 items may be purchased.". It almost sounds like the `flink-packages` project. Regards, Timo On 07.01.22 08:37, Jingsong Li wrote: Hi everyone,

[NOTICE] Introduction of flink-table-test-utils

Hi everyone, for the Scala-free planner effort we introduced a new `flink-table-test-utils`. It is recommended that connectors, formats, and catalogs use this module as a test dependency if table-common is not enough. We will fill this module with more test utilities that can also be used b

Re: [VOTE] Release 1.14.3, release candidate #1

I went through the commit diff and found the following changes that might cause issues in my opinion. Maybe it makes sense to take a second look before I will cast my vote: // change of transformations https://github.com/apache/flink/commit/b7cd97b02d7f39b5190d27fbaf6e6287f127b9a9 // change o

Re: [VOTE] Release 1.14.3, release candidate #1

out the upgrade shortcoming. The transformation changes should also be fine. The same transformation is returned. The type has changed but it is unlikely that user query the output type of a sink? Regards, Timo On 17.01.22 09:45, Timo Walther wrote: I went through the commit diff and found

Re: [VOTE] Moving connectors from Flink to external connector repositories

+1 (binding) I think this will speed up connector evolution and core development experience. Regards, Timo On 19.01.22 14:47, Martijn Visser wrote: Hi everyone, I'd like to start a vote on moving connectors from Flink to external connector repositories [1]. The vote will be open for at lea

Re: [VOTE] Creating external connector repositories

+1 (binding) Regards, Timo On 19.01.22 14:47, Martijn Visser wrote: Hi everyone, I'd like to start a vote on creating external repositories [1]. Since the thread is fairly long, I've also previously summarised it [2]. The vote will be open for at least 72 hours unless there is an objection or

Re: [ANNOUNCE] Apache Flink 1.14.3 released

Thank you so much for taking care of this Thomas and Martijn! A patch release was long overdue. Regards, Timo On 20.01.22 13:01, Till Rohrmann wrote: Thanks a lot for being our release manager Thomas and Martijn and to everyone who contributed to this release :-) Cheers, Till On Thu, Jan 20,

Re: [DISCUSS] CAST legacy behaviour

+1 Thanks for bringing up this discussion one more time Marios. I strongly support enabling the new behavior in 1.15. It definitely has implications on existing users, but as Seth said, thinking about the upcoming upgrade story we need to make sure that at least the core/basic operations are

Re: [DISCUSS] Enable scala formatting check

Big +1 This will improve the contribution experience. Even though we stopped adding more Scala code, it is still necessary from time to time. Regards, Timo Am 02.03.22 um 09:29 schrieb 刘首维: +1 I still remember my first pr. Lack of experience, I had to pay attention to Scala code format an

Re: [VOTE] Release 1.14.4, release candidate #1

+1 (binding) - I scanned the commit diff and affected files. - I could not find major API changes or otherwise problematic changes. - The biggest changes I could spot were around Kubernetes (see FLINK-20830). Thanks for taking care of this Konstantin. Timo Am 02.03.22 um 10:04 schrieb Yun Tan

[DISCUSS] Dealing with deprecated and legacy code in Flink

Hi everyone, I would like to start a discussion how we treat deprecated and legacy code in Flink in the future. During the last years, our code base has grown quite a bit and a couple of interfaces and components have been reworked on the way. I'm sure each component has a few legacy parts t

Re: [Vote] FLIP-157 Migrate Flink Documentation from Jekyll to Hugo

+1 Thanks for upgrading our docs infrastructure. Regards, Timo On 18.01.21 15:29, Seth Wiesman wrote: Hi devs, The discussion of the FLIP-157 [1] seems has reached a consensus through the mailing thread [2]. I would like to start a vote for it. The vote will be opened until 20th January (72h

Re: [DISCUSS] Correct time-related function behavior in Flink SQL

Hi Leonard, thanks for working on this topic. I agree that time handling is not easy in Flink at the moment. We added new time data types (and some are still not supported which even further complicates things like TIME(9)). We should definitely improve this situation for users. This is a pr

Re: [DISCUSS] FLIP-162: Consistent Flink SQL time function behavior

Now we have 2 discussion threads on 3 mailing lists. Which one should have prioity? Should I repost my large email here again? I think it is good to inform and invite in the user mailing lists but let's keep the FLIP discussion on the dev@ ML only. Regards, Timo On 21.01.21 16:50, Leonard Xu

Re: [DISCUSS] FLIP-162: Consistent Flink SQL time function behavior

most all user problems，the divergence is whether we need to spend pretty energy just to get a bit more accurate semantics? I think we need a tradeoff. Best, Leonard [1] https://trino.io/docs/current/functions/datetime.html#current_timestamp < https://trino.io/docs/current/functions/datetime.html#curre

Re: [DISCUSS] Dealing with deprecated and legacy code in Flink

raised a point sometime ago, that in the recent past, we developed a habit of marking everything as `@Experimental` or `@PublicEvolving` and leaving it as that forever. Maybe we should also include deadlines (2 releases since introduction?) for changing `@Experimental`/`@PublicEvolving` into `

Re: [DISCUSS] FLIP-162: Consistent Flink SQL time function behavior

. In one word, both your suggestion and my proposal can resolve almost all user problems，the divergence is whether we need to spend pretty energy just to get a bit more accurate semantics? I think we need a tradeoff. Best, Leonard [1] https://trino.io/docs/current/functions/datetime.h

Re: [DISCUSS] FLIP-162: Consistent Flink SQL time function behavior

and my proposal can resolve almost all user problems，the divergence is whether we need to spend pretty energy just to get a bit more accurate semantics? I think we need a tradeoff. Best, Leonard [1] https://trino.io/docs/current/functions/datetime.html#current_timestamp < https://tr

Re: [DISCUSS] FLIP-162: Consistent Flink SQL time function behavior

hether we need to spend pretty energy just to get a bit more accurate semantics? I think we need a tradeoff. Best, Leonard [1] https://trino.io/docs/current/functions/datetime.html#current_timestamp < https://trino.io/docs/current/functions/datetime.html#current_timestamp> [2] http

Re: [DISCUSS] FLINK-21045: Support 'load module' and 'unload module' SQL syntax

Jark Wu and Nicholas Jiang proposed to use `CREATE/DROP MODULE` instead of `LOAD/UNLOAD MODULE` because 1) From a pure SQL user's perspective, maybe `CREATE MODULE + USE MODULE` is easier to use rather than `LOAD/UNLOAD`. 2) This will be very similar to what the catalog used now.

Re: [DISCUSS] FLIP-162: Consistent Flink SQL time function behavior

osal can resolve almost all user problems，the divergence is whether we need to spend pretty energy just to get a bit more accurate semantics? I think we need a tradeoff. Best, Leonard [1] https://trino.io/docs/current/functions/datetime.html#current_timestamp < https://trin

Re: [DISCUSS] FLINK-21045: Support 'load module' and 'unload module' SQL syntax

rading the priority of the loaded module(s). 2. `LOAD/UNLOAD MODULE` v.s. `CREATE/DROP MODULE` syntax Jark Wu and Nicholas Jiang proposed to use `CREATE/DROP MODULE` instead of `LOAD/UNLOAD MODULE` because 1) From a pure SQL user's perspective, maybe `CREATE MODULE + USE MODUL

Re: [DISCUSS] FLINK-21045: Support 'load module' and 'unload module' SQL syntax

deprecated `TableFactory` class. Regarding #1, I think the point lies in whether changing the resolution order implies an `unload` operation explicitly (i.e., users could sense it). What do others think? Best, Jane On Mon, Feb 1, 2021 at 6:41 PM Timo Walther wrote: IMHO I would rather un

Re: [DISCUSS] FLIP-162: Consistent Flink SQL time function behavior

esult when user use their streaming pipeline sql to run a batch pipeline(e.g backfilling), and user also can not control these function behavior. How do you think ? Thanks, Leonard 在 2021年2月1日，18:23，Timo Walther 写道： Parts of the FLIP can already be implemented without a completed votin

Re: [DISCUSS] FLINK-21045: Support 'load module' and 'unload module' SQL syntax

Feb 1, 2021 at 10:02 PM Timo Walther wrote: +1 to Jark's proposal I like the difference between just loading and actually enabling these modules. @Rui: I would use the same behavior as catalogs here. You cannot `USE` a catalog without creating it before. Another question is whether a LOAD

Re: [DISCUSS] FLINK-21045: Support 'load module' and 'unload module' SQL syntax

g the LOAD statement instead of CREATE, so I think it's fine that it does some implicit things. Best, Jark On Tue, 2 Feb 2021 at 00:48, Timo Walther wrote: Not the module itself but the ModuleManager should handle this case, yes. Regards, Timo On 01.02.21 17:35, Jane Chan wrote: +1 to Jark&#x

Re: [DISCUSS] FLIP-162: Consistent Flink SQL time function behavior

vide consistent results. Thus, I think we may need to think more from the users' perspective. Best, Jark On Mon, 1 Feb 2021 at 23:06, Timo Walther wrote: Hi Leonard, thanks for considering this issue as well. +1 for the proposed config option. Let's start a voting thread once the

Re: [DISCUSS]FLIP-163: SQL Client Improvements

Thanks for this great proposal Shengkai. This will give the SQL Client a very good update and make it production ready. Here is some feedback from my side: 1) SQL client specific options I don't think that `sql-client.planner` and `sql-client.execution.mode` are SQL Client specific. Similar t

Re: [DISCUSS] FLINK-21045: Support 'load module' and 'unload module' SQL syntax

xecution for all of them or #2 enabled the rest modules and return a warning to users? My personal preference goes to #1 for simplicity. What do you think? Best, Jane On Tue, Feb 2, 2021 at 3:53 PM Timo Walther wrote: +1 @Jane Can you summarize our discussion in the JIRA issue? Thanks, T

Re: [DISCUSS]FLIP-163: SQL Client Improvements

se `ADD JAR` -> `CREATE JAR`, `DELETE JAR` -> `DROP JAR`, `LIST JAR` -> `SHOW JAR`. *Regarding #5*: I agree with you that we'd better keep consistent. *Regarding #6*: Yes. Most of the commands should belong to the table environment. In the Summary section, I use the tag to identify

Re: [DISCUSS]FLIP-163: SQL Client Improvements

about REMOVE vs DELETE though. While flink doesn't need to follow hive syntax, as far as I know, most users who are requesting these features are previously hive users. So I wonder whether we can support both LIST/SHOW JARS and REMOVE/DELETE JARS as synonyms? It's just like lots

[DISCUSS] FLIP-164: Improve Schema Handling in Catalogs

Hi everyone, you might have seen that we discussed a better schema API in past as part of FLIP-129 and FLIP-136. We also discussed this topic during different releases: https://issues.apache.org/jira/browse/FLINK-17793 Jark and I had an offline discussion how we can finally fix this shortco

Re: [DISCUSS]FLIP-163: SQL Client Improvements

o Alternative 1: We consider batch/streaming mode and block for batch INSERT INTO and async for streaming INSERT INTO/STATEMENT SET. And this behavior is consistent across CLI and files. Best, Jark [1]: https://github.com/apache/flink/blob/master/flink-end-to-end-tests/flink-end-to-end-tests-comm

Re: [DISCUSS]FLIP-163: SQL Client Improvements

tible, and provides flexible configurable behavior 3) sync for both batch and streaming DML, and can be set to async via a configuration. ==> +0 for this, because it breaks all the compatibility, esp. our main users. Best, Jark On Mon, 8 Feb 2021 at 17:34, Timo Walther wrote: Hi Jark, Hi

Re: [DISCUSS]FLIP-163: SQL Client Improvements

th a Flink job detach mode. How about `table.dml-async`? Thanks, Timo On 08.02.21 15:55, Jark Wu wrote: Thanks Timo, I'm +1 for option#2 too. I think we have addressed all the concerns and can start a vote. Best, Jark On Mon, 8 Feb 2021 at 22:19, Timo Walther wrote: Hi Jark, you are

Re: [DISCUSS]FLIP-163: SQL Client Improvements

Hi everyone, I understand Rui's concerns. `table.dml-sync` should not apply to regular `executeSql`. Actually, this option makes only sense when executing multi statements. Once we have a `TableEnvironment.executeMultiSql()` this config could be considered. Maybe we can find a better generic

Re: [DISCUSS]FLIP-163: SQL Client Improvements

uteMultiSql() in the future, right? Best, Jark On Tue, 9 Feb 2021 at 16:37, Timo Walther wrote: Hi everyone, I understand Rui's concerns. `table.dml-sync` should not apply to regular `executeSql`. Actually, this option makes only sense when executing multi statements. Once we have a `TableEn

Re: [DISCUSS] FLIP-164: Improve Schema Handling in Catalogs

look good. I agree it is an important step towards FLIP-129 and FLIP-136. Personally I feel comfortable voting on the document. Best, Dawid On 05/02/2021 16:09, Timo Walther wrote: Hi everyone, you might have seen that we discussed a better schema API in past as part of FLIP-129 and FLIP-13

Re: [DISCUSS] FLIP-164: Improve Schema Handling in Catalogs

to me overall. I have two questions. 1. When should we use a resolved schema and when to use an unresolved one? 2. The FLIP mentions only resolved tables/views can be stored into a catalog. Does that mean the getTable method should also return a resolved object? On Tue, Feb 9, 2021 at 6:29 PM Timo Wa

Re: [DISCUSS] FLIP-164: Improve Schema Handling in Catalogs

? If we want to introduce a new stack, it would be better to have a different name, otherwise, it's easy to use a wrong class for users. Best, Jark On Wed, 10 Feb 2021 at 09:49, Rui Li wrote: I see. Makes sense to me. Thanks Timo for the detailed explanation! On Tue, Feb 9, 2021 at 9:48 PM

Re: [DISCUSS] FLIP-164: Improve Schema Handling in Catalogs

declaration. Regards, Timo On 10.02.21 12:12, Timo Walther wrote: Hi Jark, I don't think many users use WatermarkSpec. UniqueConstraint could cause some confusion but this mostly affects catalog or connector implementers. After deprecating the old APIs it should be obvious when an out

[VOTE] FLIP-164: Improve Schema Handling in Catalogs

Hi everyone, I'd like to start a vote on FLIP-164 [1] which was discussed in [2]. The vote will be open for at least 72 hours. Unless there are any objections, I'll close it by February 17th, 2021 (due to weekend) if we have received sufficient votes. [1] https://cwiki.apache.org/confluence/

Re: [DISCUSS]FLIP-163: SQL Client Improvements

I am fine with the new option name. Best, Shengkai Timo Walther 于2021年2月9日 周二下午5:35写道： Yes, `TableEnvironment#executeMultiSql()` can be future work. @Rui, Shengkai: Are you also fine with this conclusion? Thanks, Timo On 09.02.21 10:14, Jark Wu wrote: I'm fine with `table.multi-dml-

Re: [VOTE] FLIP-164: Improve Schema Handling in Catalogs

21 at 8:25 AM Jark Wu wrote: +1 (binding) Best, Jark 2021年2月12日 20:37，Dawid Wysakowicz 写道： +1 (binding) Best, Dawid On 12/02/2021 13:33, Timo Walther wrote: Hi everyone, I'd like to start a vote on FLIP-164 [1] which was discussed in [2]. The vote will be open for at least 72 hou

[RESULT][VOTE] FLIP-164: Improve Schema Handling in Catalogs

Sorry, I forgot to add the [RESULT] label in the mail's subject. I'm sending this mail to satisfy the process. Regards, Timo On 18.02.21 12:02, Timo Walther wrote: Hi everyone, The voting time for FLIP-164: Improve Schema Handling in Catalogs [1] has passed. I'm closi

Re: [VOTE] FLIP-163: SQL Client Improvements

+1 (binding) Thanks, Timo On 22.02.21 04:44, Jark Wu wrote: +1 (binding) Best, Jark On Mon, 22 Feb 2021 at 11:06, Shengkai Fang wrote: Hi devs It seems we have reached consensus on FLIP-163[1] in the discussion[2]. So I'd like to start the vote for this FLIP. Please vote +1 to approve th

Re: [DISCUSS]FLIP-163: SQL Client Improvements

tax is SQL-client-specific, but if it's general Flink SQL syntax we should consider this (one way or another). Regards Ingo On Fri, Feb 12, 2021 at 3:53 PM Timo Walther wrote: Hi Shengkai, thanks for updating the FLIP. I have one last comment for the option `table.execution.mode`. Should

Re: [DISCUSS]FLIP-163: SQL Client Improvements

we might cause if we introduce such a method of our own, I think it's better to wait for some more feedback. Best, Kurt On Tue, Feb 23, 2021 at 9:45 PM Timo Walther wrote: Hi Kurt, we can also shorten it to `table.dml-sync` if that would help. Then it would confuse users that do a regular

[DISCUSS] Deprecation and removal of the legacy SQL planner

Hi everyone, since Flink 1.9 we have supported two SQL planners. Most of the original plan of FLIP-32 [1] has been implemented. The Blink code merge has been completed and many additional features have been added exclusively to the new planner. The new planner is now in a much better shape tha

Re: [DISCUSS]FLIP-163: SQL Client Improvements

on. I don't think the drawback is really critical because many systems have commands play the same role with the different names. Best, Shengkai Timo Walther 于2021年2月25日周四 下午4:23写道： The `table.` prefix is meant to be a general option in the table ecosystem. Not necessarily attached to

Re: [DISCUSS] FLIP-162: Consistent Flink SQL time function behavior

ther systems and databases will evaluate these functions during query start. And for streaming users, I have already seen some users are expecting these functions to be calculated per record. Thus I think we can make the behavior determined together with execution mode. One exception would be PROCTIME(),

Re: [DISCUSS] FLIP-162: Consistent Flink SQL time function behavior

and btw it is interesting to notice that AWS seems to do the approach that I suggested first. All functions are SQL standard compliant, and only dedicated functions with a prefix such as CURRENT_ROW_TIMESTAMP divert from the standard. Regards, Timo On 01.03.21 08:45, Timo Walther wrote: How

Re: [DISCUSS] FLIP-162: Consistent Flink SQL time function behavior

we will suffer from such config option, because users can always make Flink SQL have strange behavior by setting this config to an undesired way. I prefer to not introduce such config until we have to. Leonard's proposal already makes almost all users happy thus I think we can still wait. Best

Re: [DISCUSS] Splitting User support mailing list

I would vote -0 here. I fear that we are creating potential silos where a team doesn't know what is going on in the other teams. Regards, Timo On 01.03.21 10:47, Jark Wu wrote: I also have some concerns about splitting python and sql. Because I have seen some SQL questions users reported bu

Re: [DISCUSS] FLIP-162: Consistent Flink SQL time function behavior

Best, Kurt On Mon, Mar 1, 2021 at 3:58 PM Timo Walther wrote: and btw it is interesting to notice that AWS seems to do the approach that I suggested first. All functions are SQL standard compliant, and only dedicated functions with a prefix such as CURRENT_ROW_TIMESTAMP divert from the sta

Re: [DISCUSS]FLIP-163: SQL Client Improvements

Kurt Young 于2021年3月1日周一 下午5:11写道： I'm +1 for either: 1. introduce a sql client specific option, or 2. Introduce a table config option and make it apply to both table module & sql client. It would be the FLIP owner's call to decide. Best, Kurt On Mon, Mar 1, 2021 at 3:25 PM

Re: [VOTE] FLIP-162: Consistent Flink SQL time function behavior

+1 (binding) Regards, Timo On 03.03.21 04:14, Jark Wu wrote: +1 (binding) Best, Jark On Tue, 2 Mar 2021 at 10:42, Leonard Xu wrote: Hi all, I would like to start the vote for FLIP-162 [1], which has been discussed and reached a consensus in the discussion thread [2]. Please vote +1 to ap

Re: [DISCUSS] Deprecation and removal of the legacy SQL planner

's better for us to be more focused on a single planner. Your proposed roadmap looks good to me, +1 from my side and thanks again for all your efforts! Best, Kurt On Thu, Feb 25, 2021 at 5:01 PM Timo Walther wrote: Hi everyone, since Flink 1.9 we have supported two SQL planners. Most of

Re: [DISCUSS] FLIP-162 follow-up discussion

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 hope the new functions will be well-tested so that a fallback to the old functions is not necessary as a workaround. It will definitely avoid confusion for u

Re: [DISCUSS] Deprecation and removal of the legacy SQL planner

20:59, Leonard Xu wrote: +1 for the roadmap. Thanks Timo for driving this. Best, Leonard 在 2021年3月4日，20:40，Timo Walther 写道： Last call for feedback on this topic. It seems everyone agrees to finally complete FLIP-32. Since FLIP-32 has been accepted for a very long time, I think we don&#

Re: Apply external 3 days for FLINK-20387 after feature freeze

Hi everyone, I support Leonard's request. It was foreseeable that the changes of FLIP-162 will be massive and will take some time. By looking at PRs such as https://github.com/apache/flink/pull/15280 I would also vote for giving a bit more time for proper reviews and finalizing this story fo

<    1   2   3   4   5   6   7   8   9   10   >