Re: [DISCUSS] Flink project bylaws

Hi all, Sorry for joining late. I just wanted to say that I really like the proposed bylaws! One comment, I also have the same concerns as expressed by few people before that the "committer +1" on code change might be hard to achieve currently. On the other hand I would say this would be benefici

Re: [ANNOUNCE] Jiangjie (Becket) Qin has been added as a committer to the Flink project

Congratulations Becket! Good to have you onboard! On 18/07/2019 10:56, Till Rohrmann wrote: > Congrats Becket! > > On Thu, Jul 18, 2019 at 10:52 AM Jeff Zhang wrote: > >> Congratulations Becket! >> >> Xu Forward 于2019年7月18日周四 下午4:39写道： >> >>> Congratulations Becket! Well deserved. >>> >>> >>> Ch

[DISCUSS] Support temporary tables in SQL API

Hi all, When working on FLINK-13279[1] we realized we could benefit from a better temporary objects support in the Catalog API/Table API. Unfortunately we are already long past the feature freeze that's why I wanted to get some opinions from the community how should we proceed with this topic. I t

Re: [DISCUSS] Support temporary tables in SQL API

the details. >>> >>> Thanks, >>> Xuefu >>> >>> On Mon, Jul 22, 2019 at 7:19 AM Timo Walther wrote: >>> >>>> Thanks for summarizing our offline discussion Dawid! Even though I would >>>> prefer solution 1 instead of rele

Re: [ANNOUNCE] Kete Young is now part of the Flink PMC

Congratulations! Best, Dawid On 23/07/2019 13:39, Hequn Cheng wrote: > Congratulations Kurt! > > Best, Hequn > > On Tue, Jul 23, 2019 at 7:27 PM vino yang wrote: > >> Congratulations Kurt! >> >> Bo WANG 于2019年7月23日周二 下午7:13写道： >> >>> Congratulations Kurt! >>> >>> >>> Best, >>> >>> Bo WANG >>>

Re: [ANNOUNCE] Zhijiang Wang has been added as a committer to the Flink project

Congratulations! Best, Dawid On 23/07/2019 12:03, Danny Chan wrote: > Congratulations Zhijiang! > > Best, > Danny Chan > 在 2019年7月22日 +0800 PM10:12，dev@flink.apache.org，写道： >> Congratulations Zhijiang! signature.asc Description: OpenPGP digital signature

Re: [DISCUSS] Support temporary tables in SQL API

>> new feature (multiple catalogs), which seems very natural. >> >> Thanks, >> Xuefu >> >> On Tue, Jul 23, 2019 at 5:47 AM Dawid Wysakowicz > <mailto:dwysakow...@apache.org>> >> wrote: >> >>> I think we all agree so far that

Re: [DISCUSS] Repository split

First of all I don't have much(if not at all) experience with working with a multi repository project of Flink's size. I would like to mention a few thoughts of mine, though. In general I am slightly against splitting the repository. I fear that what we actually want to do is to introduce double st

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

Hi Gyula, As for the issues with mapr maven repository, you might have a look at this message: https://lists.apache.org/thread.html/77f4db930216e6da0d6121065149cef43ff3ea33c9ffe9b1a3047210@%3Cdev.flink.apache.org%3E Try using the "unsafe-mapr-repo" profile. Best, Dawid On 11/08/2019 19:31, Gyu

Re: [VOTE] Flink Project Bylaws

+1(non-binding) I really think this will improve many aspects of how our community operates. Thank you Becket for kicking it off! Best, Dawid On 11/08/2019 10:07, Becket Qin wrote: > Hi all, > > I would like to start a voting thread on the project bylaws of Flink. It > aims to help the communit

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

t;>>>>>>>>>> correct >>>>>>>>>>>>> the >>>>>>>>>>>>>>> "Fix >>>>>>>>>>>>>>>> Version" of the correspondi

Re: [VOTE] FLIP-51: Rework of the Expression Design

+1 from my side Best, Dawid On 16/08/2019 10:31, Jark Wu wrote: > +1 from my side. > > Thanks Jingsong for driving this. > > Best, > Jark > > On Thu, 15 Aug 2019 at 22:09, Timo Walther wrote: > >> +1 for this. >> >> Thanks, >> Timo >> >> Am 15.08.19 um 15:57 schrieb JingsongLee: >>> Hi Flink de

Re: [VOTE] Flink Project Bylaws

AFAIK this voting scheme is described in the "Modifying Bylaws" section, in the end introducing bylaws is a modify operation ;) . I think it is a valid point to CC priv...@flink.apache.org in the future. I wouldn't say it is a must though. The voting scheme requires that every PMC member has to be

Re: [DISCUSS] FLIP-54: Evolve ConfigOption and Configuration

Hi Stephan, Thank you for your opinion. Actually list/composite types are the topics we spent the most of the time. I understand that from a perspective of a full blown type system, a field like isList may look weird. Please let me elaborate a bit more on the reason behind it though. Maybe we wer

Re: [DISCUSS][CODE STYLE] Usage of Java Optional

Hi Andrey, Just wanted to quickly elaborate on my opinion. I wouldn't say I am -1, just -0 for the Optionals in private methods. I am ok with not forbidding them there. I just think in all cases there is a better solution than passing the Optionals around, even in private methods. I just hope the

Re: [CODE-STYLE] Builder pattern

Hi Gyula, A few comments from my side. Ad. 1 Personally I also prefer a static method in the "built" class. Not sure if I would be that strict about the "Builder" suffix, though. It is usually quite easy to realize the method returns a builder rather than the object itself. In my opinion the suff

Re: [VOTE] FLIP-54: Evolve ConfigOption and Configuration

+1 to the FLIP Also I think we should mention that the voting will last at least 72 hours as requested by the bylaws until 30 Aug 14:00 CEST. (Correct me if I am wrong Timo) On 27/08/2019 13:32, Jark Wu wrote: > +1 to the FLIP. > > > Regards, > Jark > >> 在 2019年8月27日，19:28，Timo Walther 写道： >> >>

Re: [VOTE] FLIP-54: Evolve ConfigOption and Configuration

Actually I wanted to propose a slight change to the proposal. Therefore I want to change my vote to -1 for now. I suggest to change the Configurable interface to ConfigurableFactory: public interface ConfigurableFactory {     /**     * Creates an instance from the given configuration.     */

[DISCUSS] FLIP-59: Enable execution configuration from Configuration object

Hi, I wanted to propose a new, additional way of configuring execution parameters that can currently be set only on such objects like ExecutionConfig, CheckpointConfig and StreamExecutionEnvironment. This poses problems such as: * no easy way to configure those from a file * there is no easy

Re: [DISCUSS] FLIP-54: Evolve ConfigOption and Configuration

ering an explicit >>>>>>>> `intType()` method etc. The current design of validators centered >>>>>>>> around Java classes makes it possible to have typical domain >>>>>>>> validators baked by generics as you suggested. If we in

Re: [DISCUSS] FLIP-59: Enable execution configuration from Configuration object

; if we need. > > Ship it! > > Gyula > > On Thu, Aug 29, 2019 at 5:05 PM Dawid Wysakowicz > wrote: > >> Hi, >> >> I wanted to propose a new, additional way of configuring execution >> parameters that can currently be set only on such objects like

Re: [VOTE] FLIP-54: Evolve ConfigOption and Configuration

+1 to the design On 29/08/2019 15:53, Timo Walther wrote: > I converted the mentioned Google doc into a wiki page: > > https://cwiki.apache.org/confluence/display/FLINK/FLIP-54%3A+Evolve+ConfigOption+and+Configuration > > > The core semantics have not changed. > > Happy voting, > Timo > > On 29.08

Re: [DISCUSS] FLIP-60: Restructure the Table API & SQL documentation

+1 to the idea of restructuring the docs. My only suggestion to consider is how about moving the User-Defined-Extensions subpages to corresponding broader topics? Sources & Sinks >> Connect to external systems Catalogs >> Connect to external systems and then have a Functions sections with subse

Re: [DISCUSS] Simplify Flink's cluster level RestartStrategy configuration

Also +1 in general. I have a few questions though: - does it only apply to the logic in org.apache.flink.runtime.executiongraph.restart.RestartStrategyFactory#createRestartStrategyFactory, which is only the cluster side configuration? Or do you want to change the logic also on the job side in Exe

Re: [DISCUSS] FLIP-59: Enable execution configuration from Configuration object

of scope at first. > > Cheers, > Gyula > > On Fri, Aug 30, 2019 at 12:13 PM Dawid Wysakowicz > wrote: > >> Hi Gyula, >> >> Thank you for the support on those changes. >> >> I am not sure if I understood your idea for the "reconfigurati

Re: [DISCUSS] FLIP-54: Evolve ConfigOption and Configuration

igurations. >>>> >>>> Re: 2 >>>> >>>>> I think about the withExtendedDescription as a helper getter in a >>>>> different place, so that the option is easier to find in a different >>>>> module from it was defined. >

Re: Please add me as contributor

Hi Jan, Recently the community changed the contribution process a bit and there are no longer contributor privileges. The jira issues are supposed to be assigned by committers that are willing to help you with getting the contribution in. Please look at the contribution guidelines[1]. Do you have

Re: [DISCUSS] FLIP-57 - Rework FunctionCatalog

Hi all, Just an opinion on the built-in <> temporary functions resolution and NAMING issue. I think we should not allow overriding the built-in functions, as this may pose serious issues and to be honest is rather not feasible and would require major rework. What happens if a user wants to overrid

Re: [DISCUSS] FLIP-54: Evolve ConfigOption and Configuration

Hi Becket, You are right, that what we had in mind for ExecutionConfig/CheckpointConfig etc. is the option b) from your email. In the context of the FLIP-54, those objects are not Configurable. What we understood as a Configurable by the FLIP-54 are a simple pojos, that are stored under a single k

Re: [DISCUSS] FLIP-57 - Rework FunctionCatalog

DB qualifier allowed. Can overwrite built-in. >>> 2. Spark: basically follows Hive ( >>> >>> https://docs.databricks.com/spark/latest/spark-sql/language-manual/create-function.html >>> >>> ) >>> 3. SAP SQL Anywhere Server: can have owner (db?). Not s

[DISCUSS] FLIP-64: Support for Temporary Objects in Table module

Hi all, As part of FLIP-30 a Catalog API was introduced that enables storing table meta objects permanently. At the same time the majority of current APIs create temporary objects that cannot be serialized. We shoul

Re: [DISCUSS] FLIP-57 - Rework FunctionCatalog

>> >> ***Seems we have consensus that users should be able to use built-in >> functions of Hive or other external systems in SQL explicitly and >> deterministically regardless of Flink built-in functions and the potential >> modular built-in functions, via some new synt

Re: [DISCUSS] FLIP-57 - Rework FunctionCatalog

is simpler and more generic. That's why I > suggested we look more into this direction. > > Please let me know if there are further questions. > > Thanks, > Xuefu > > > > > On Thu, Sep 5, 2019 at 2:42 PM Dawid Wysakowicz > wrote: > >> Hi Xuefu, &

Re: [DISCUSS] FLIP-64: Support for Temporary Objects in Table module

Hi all, @Jingsong Could you elaborate a bit more what do you mean by /"//some Connectors//are difficult to convert all states to properties"/ All the Flink provided connectors will definitely be expressible with properties (In the end you should be able to use them from DDL). I think if a TableS

Re: [DISCUSS] FLIP-57 - Rework FunctionCatalog

der is equivalent in the two approaches. >> >> By the way, resolution order matters only for simple name reference. For >> names such as db.function (interpreted as current_cat/db/function) or >> cat.db.function, the reference is unambiguous, so on resolution is needed. >&g

Re: [ANNOUNCE] Kostas Kloudas joins the Flink PMC

Congratulations Klou! Best, Dawid On 06/09/2019 14:55, Fabian Hueske wrote: > Hi everyone, > > I'm very happy to announce that Kostas Kloudas is joining the Flink PMC. > Kostas is contributing to Flink for many years and puts lots of effort in > helping our users and growing the Flink community.

Re: [DISCUSS] FLIP-57 - Rework FunctionCatalog

late some objects in the catalog that's managed by other teams, but > > are allowed to manipulate some other objects (temp functions in this > case) > > belonging to the catalog in namespaces, users may think we introduced > extra > > complexity and confusion with some kind o

Re: [DISCUSS] FLIP-57 - Rework FunctionCatalog

Hi, Another idea to consider on top of Timo's suggestion. How about we have a special namespace (catalog + database) for built-in objects? This catalog would be invisible for users as Xuefu was suggesting. Then users could still override built-in functions, if they fully qualify object with the bu

Re: [DISCUSS] FLIP-57 - Rework FunctionCatalog

gt; >>>> > > >>>> It seems to me that there is a general consensus on having temp > > functions > > >>>> that have no namespaces and overwrite built-in functions. (As a side > > note > > >>>> for comparability, the current user defined

Re: [DISCUSS] FLIP-57 - Rework FunctionCatalog

Dawid Wysakowicz, wrote: > Hi, > I think it makes sense to start voting at this point. > > Option 1: Only 1-part identifiers > PROS: > - allows shadowing built-in functions > CONS: > - incosistent with all the other objects, both permanent & temporary > - does not al

Re: [DISCUSS] FLIP-57 - Rework FunctionCatalog

gt; keyword for this create DDL. For other places (such as function > referencing), no keyword or special namespace is needed. > > Thanks, > Xuefu > > On Wed, Sep 18, 2019 at 4:32 PM Dawid Wysakowicz < > wysakowicz.da...@gmail.com> > wrote: > > > Hi, > &g

Re: [DISCUSS] FLIP-64: Support for Temporary Objects in Table module

Hi JingsongLee, >From my understanding they can. Underneath they will be CatalogTables. The difference is the lifetime of the tables. Plus some of the user facing interfaces cannot be persisted e.g. datastream. Therefore we must have a separate methods for that. In the end the temporary tables are

Re: [DISCUSS] [FLINK-32873] Add a config to allow disabling Query hints

Hey all, My understanding was that from the first message we were discussing throwing an exception. Oracle was only shown as an example of a system that have a flag for hints behaviour. Let's get back to the discussion and agree on the behavior. My suggestion is to introduce an enum instead o

Re: [DISCUSS] [FLINK-32873] Add a config to allow disabling Query hints

ards, Jing On Thu, Oct 5, 2023 at 12:23 AM Sergey Nuyanzin wrote: Hi Dawid, Thanks for bringing this. I would agree with enum approach ignored option would allow to follow Oracle's behavior as well table.optimizer.query-options = ENABLED/DISABLED/IGNORED nit: Can we have "hint&q

Re: [VOTE] FLIP-376: Add DISTRIBUTED BY clause

+1 Best, Dawid On Mon, 6 Nov 2023 at 12:38, Timo Walther wrote: > Hi everyone, > > I'd like to start a vote on FLIP-376: Add DISTRIBUTED BY clause[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.

[DISCUSS] FLIP-393: Make QueryOperations SQL serializable

Hi, I would like to propose a follow-up improvement to some of the work that has been done over the years to the Table API. I posted the proposed changes in the FLIP-393. I'd like to get to know what others think of choosing SQL as the serialization format for QueryOperations. Regards,

Re: [DISCUSS] FLIP-393: Make QueryOperations SQL serializable

s still in preliminary state, you just want to gather ideas > about whether to use SQL or something else as the serialization format > for QueryOperation? > > Dawid Wysakowicz 于2023年11月15日周三 19:34写道： > > > > Hi, > > I would like to propose a follow-up improvement to

Re: [DISCUSS] FLIP-393: Make QueryOperations SQL serializable

traction of Calcite's RelNode, with some exceptions such as > PlannerQueryOperation. > > [1] > https://github.com/apache/calcite/blob/153796f8994831ad015af4b9036aa01ebf78/core/src/main/java/org/apache/calcite/rel/rel2sql/SqlImplementor.java#L141 > > Dawid Wysakowicz 于2023年11月16日周四 16:24写道： >

Re: [DISCUSS] FLIP-393: Make QueryOperations SQL serializable

he overall proposal. > > Regards, > Xiangyu > > Benchao Li 于2023年11月17日周五 19:07写道： > > > That sounds good to me, I'm looking forward to it! > > > > After this FLIP is done, FLINK-25015 can utilize this ability to set > > job name for queries. >

[VOTE] FLIP-393: Make QueryOperations SQL serializable

Hi everyone, Thank you to everyone for the feedback on FLIP-393: Make QueryOperations SQL serializable[1] which has been discussed in this thread [2]. I would like to start a vote for it. The vote will be open for at least 72 hours unless there is an objection or not enough votes. [1] https://cw

Re: [VOTE] FLIP-393: Make QueryOperations SQL serializable

> > > > > > > > > > > > > > Lookgin forward to this! > > > > > > > > > > > > > > Best, > > > > > > > Ferenc > > > > > > > > > > > > >

[RESULT][VOTE] FLIP-393: Make QueryOperations SQL serializable

(binding) Dawid Wysakowicz (binding) Ferenc Csaky (non-binding) Xiangyu Feng (non-binding) Jim Hughes (non-binding) Thanks to all involved. [1] https://cwiki.apache.org/confluence/x/vQ2ZE [2] https://lists.apache.org/thread/5txkmqx9wfj0lzg02vnrw99cj63b5zvj Best, Dawid

Re: [VOTE] Release flink-shaded 18.0, release candidate #1

+1 (binding) - Validated hashes - Verified signature - Verified that no binaries exist in the source archive Best, Dawid On Tue, 28 Nov 2023 at 23:10, Sergey Nuyanzin wrote: > Hi everyone, > Please review and vote on the release candidate #1 for the version 18.0, as > follows: > [ ] +1, Approv

Re: [DISCUSS][FLINK-31830] Align the Nullability Handling of ROW between SQL and TableAPI

Hey all, First of all, sorry I have not read the entire thread. I just wanted to make sure you take this one case into consideration. As far as I know, we map java classes to SQL ROWs? E.g. it is possible to have a POJO as a parameter to a UDF. *class MyUDF {* * eval(MyPojo a)* *}* *class MyP

Re: Re: [VOTE] Accept Flink CDC into Apache Flink

+1 (binding) Best, Dawid On Wed, 10 Jan 2024 at 11:54, Piotr Nowojski wrote: > +1 (binding) > > śr., 10 sty 2024 o 11:25 Martijn Visser > napisał(a): > > > +1 (binding) > > > > On Wed, Jan 10, 2024 at 4:43 AM Xingbo Huang wrote: > > > > > > +1 (binding) > > > > > > Best, > > > Xingbo > > > > >

[VOTE] FLIP-55: Introduction of a Table API Java Expression DSL

Hi all, I wanted to resurrect the thread about introducing a Java Expression DSL. Please see the updated flip page[1]. Most of the flip was concluded in previous discussion thread. The major changes since then are: * accepting java.lang.Object in the Java DSL * adding $ interpolation for a colum

[DISCUSS] Drop connectors for Elasticsearch 2.x and 5.x

Hi all, As described in this https://issues.apache.org/jira/browse/FLINK-11720 ticket our elasticsearch 5.x connector does not work out of the box on some systems and requires a version bump. This also happens for our e2e. We cannot bump the version in es 5.x connector, because 5.x connector share

Re: [VOTE] FLIP-55: Introduction of a Table API Java Expression DSL

cted to java.lang.Object? literal >>> object or expression? So the Object is the grammatical sugar of literal? >>> >>> Best, >>> Jingsong Lee >>> >>> On Mon, Feb 10, 2020 at 9:40 PM Timo Walther wrote: >>> >>>> +1 for this.

[VOTE][RESULT] FLIP-55: Introduction of a Table API Java Expression DSL

the Java DSL, without >>> scala implicit conversion, a lot of "lit" look unfriendly to users. >>> Best, >>> Jingsong Lee >>> On Tue, Feb 11, 2020 at 6:07 PM Dawid Wysakowicz >>> wrote: >>>> Hi, >>>> >>>>

[DISCUSS][TABLE] Issue with package structure in the Table API

Hi devs, I wanted to bring up a problem that we have in our package structure. As a result of https://issues.apache.org/jira/browse/FLINK-13045 we started advertising importing two packages in the scala API: import org.apache.flink.table.api._ import org.apache.flink.table.api.scala._ The intent

Re: [DISCUSS] Drop connectors for Elasticsearch 2.x and 5.x

t that? >> >> >> On Tue, Feb 11, 2020 at 6:28 AM Danny Chan wrote: >> >>> 5.x seems to have a lot of users, is the 6.x completely compatible with >>> 5.x ~ >>> >>> Best, >>> Danny Chan >>> 在 2020年2月10日 +0800 PM9:45，Dawid Wys

Re: [ANNOUNCE] Jingsong Lee becomes a Flink committer

Congratulations Jingsong! Best, Dawid On 24/02/2020 08:12, zhenya Sun wrote: > Congratulations！！！ > | | > zhenya Sun > | > | > toke...@126.com > | > 签名由网易邮箱大师定制 > > > On 02/24/2020 14:35，Yu Li wrote： > Congratulations Jingsong! Well deserved. > > Best Regards, > Yu > > > On Mon, 24 Feb 2020 at 1

Re: [DISCUSS] Support notFollowedBy with interval as the last part of a Pattern

Hi Shuai, First of all let me apologize for a late reply. Unfortunately I don't have enough capacity to properly review and help with the proposal at this time. If there is another committer in the community willing to shepherd the proposal feel free to proceed with it. Another suggestion I may h

Re: TIME/TIMESTAMP parse in Flink TABLE/SQL API

hand, CsvRowDeserializationSchema supports to parse > "2019-07-09 02:02:00.040". > > So the question is shall we insist on the RFC-3339 "standard"? > Shall we loosen it for usability?  > What do you think @Dawid Wysakowicz <mailto:dwysakow...@apache.org

[DISCUSS] FLIP-107: Reading table columns from different parts of source records

Hi, I would like to propose an improvement that would enable reading table columns from different parts of source records. Besides the main payload majority (if not all of the sources) expose additional information. It can be simply a read-only metadata such as offset, ingestion time or a read and

Re: [DISCUSS] FLIP-107: Reading table columns from different parts of source records

roperties more hierarchical? > For example, "timestamp" => "connector.timestamp"? (actually, I prefer > "kafka.timestamp" which is another improvement for properties FLINK-12557) > A single "timestamp" in properties may mislead users that

Re: [DISCUSS] FLIP-107: Reading table columns from different parts of source records

ps://dev.mysql.com/doc/refman/5.7/en/partitioning-hash.html > [2] > https://docs.oracle.com/database/121/VLDBG/GUID-F023D3ED-262F-4B19-950A-D3C8F8CDB4F4.htm#VLDBG1270 > > Best, > Danny Chan > 在 2020年3月2日 +0800 PM6:16，Dawid Wysakowicz ，写道： >> Hi Jark, >> Ad. 2 I added a se

[DISCUSS] FLIP-110: Support LIKE clause in CREATE TABLE

Hi devs, I wanted to bring another improvement proposal up for a discussion. Often users need to adjust existing tables slightly. This is especially useful when users need to enhance a table created from an external tool (e.g. HIVE) with Flink's specific information such as e.g watermarks. It can

Re: [DISCUSS] FLIP-110: Support LIKE clause in CREATE TABLE

afka table, and the new Kafka > table exactly matches the underlying physical data format? > > Best, > Jark > > [1]: https://www.postgresql.org/docs/9.5/sql-createtable.html > [2]: > > https://cwiki.apache.org/confluence/display/Hive/LanguageManual+DDL#LanguageManualDDL-Cre

Re: [DISCUSS] FLIP-106: Support Python UDF in SQL Function DDL

Hi all, I had a really quick look and from my perspective the proposal looks fine. I share Jarks opinion that the instantiation could be done at a later stage. I agree with Wei it requires some changes in the internal implementation of the FunctionCatalog, to store temporary functions as catalog fu

Re: [DISCUSS] FLIP-95: New TableSource and TableSink interfaces

Hi Timo, Thank you for the proposal. I think it is an important improvement that will benefit many parts of the Table API. The proposal looks really good to me and personally I would be comfortable with voting on the current state. Best, Dawid On 23/03/2020 18:53, Timo Walther wrote: > Hi every

Re: [DISCUSS] FLIP-95: New TableSource and TableSink interfaces

et of connector interface for both Table and DataStream, > rather than having two hierarchies. I am not 100% sure if this would work, > but if it works, this would be a huge win from both code maintenance and > user experience perspective. > > Thanks, > > Jiangjie (Becket) Qin >

Re: [DISCUSS] FLIP-110: Support LIKE clause in CREATE TABLE

so very useful for many cases. >> >> 2.For LIKE statement in schema, I know two kinds of like syntax, one is >> MySQL/hive/sqlserver, the other is PostgreSQL. I prefer former: >> - In the FLIP, there is "OVERWRITING OPTIONS", this will overwrite >> properties

Re: [DISCUSS] FLIP-95: New TableSource and TableSink interfaces

; we >>>>> should be confident in the current change. >>>>> >>>>> Best, >>>>> Jingsong Lee >>>>> >>>>> On Tue, Mar 24, 2020 at 4:30 PM Timo Walther >>> wrote: >>>>>> @Becke

Re: [DISCUSS] FLIP-110: Support LIKE clause in CREATE TABLE

one is >> MySQL/hive/sqlserver, the other is PostgreSQL. I prefer former: >> - In the FLIP, there is "OVERWRITING OPTIONS", this will overwrite >> properties in "with"? This looks weird, because "LIKE" is in schema, but it >> can affect outside

Re: Flink CEP greedy match of single pattern

Hi Dominik, I think you are hitting a bug. The greedy quantifier does not work well if applied for the last element of a pattern. There is a jira issue to improve support for greedy qualifier[1]. You could work it around with adding an additional state at the end. E.g. : Pattern.begin[AccelVecto

Re: [DISCUSS] FLIP-95: New TableSource and TableSink interfaces

myTableSource.applyFilterPredicate(expression); >>>>>>>> ... >>>>>>>> } >>>>>>>> >>>>>>>> TableFactory and TableSource are not directly exposed to end users, >>>> all >>

Re: [Discuss] FLINK-16039 Add API method to get last element in session window

Hi Manas, First of all I think your understanding of how the session windows work is correct. I tend to slightly disagree that the end for a session window is wrong. It is my personal opinion though. I see it this way that a TimeWindow in case of a session window is the session itself. The sessio

Re: [DISCUSS] FLIP-122: New Connector Property Keys for New Factory

Hi all, I like the overall design of the FLIP. As for the withstanding concerns. I kind of like the approach to put the version into the factory identifier. I think it's the cleanest way to say that this version actually applies to the connector itself and not to the system it connects to. BTW, I

Re: [DISCUSS] FLIP-122: New Connector Property Keys for New Factory

gt;> If we have this outcome, the interface of Factory#factoryVersion is not >>>> needed anymore, this can simplify the learning cost of new factory. >>>> We may need to update FLIP-95 and re-vote for it? cc @Timo Walther >>>> >>>> >>>

Re: [DISCUSS] FLIP-110: Support LIKE clause in CREATE TABLE

LIKE clause to the very end? > > CREATE TABLE X () WITH () LIKE ... > > Otherwise, the LIKE clause looks a bit lost if there are options > afterwards. Otherwise, +1 for start a vote from my side. > > Regards, > Timo > > > On 25.03.20 15:30, Dawid Wysakowicz wrote:

[VOTE] FLIP-110: Support LIKE clause in CREATE TABLE

Hi all, I would like to start the vote for FLIP-110 [1], which is discussed and reached a consensus in the discussion thread [2]. The vote will be open until April 3rd (72h), unless there is an objection or not enough votes. Best, Dawid [1] https://cwiki.apache.org/confluence/display/FLINK/FLI

Re: [DISCUSS] FLIP-110: Support LIKE clause in CREATE TABLE

ge the meaning of "CONSTRAINTS, OPTIONS" in the example, but it is > hard to guess "GENERATED". > - Which category does partition keys belong to? > > (I am sorry if I've disturbed the vote thread, because in my Gmail view, > they're the same thread.) > > B

Re: [VOTE] FLIP-110: Support LIKE clause in CREATE TABLE

inconvenience. Best, Dawid On 31/03/2020 09:43, Timo Walther wrote: > +1 this will reduce manual schema work a lot! > > Thanks, > Timo > > On 31.03.20 09:33, Dawid Wysakowicz wrote: >> Hi all, >> >> I would like to start the vote for FLIP-110 [1], which is dis

Re: [DISCUSS] FLIP-84 Feedback Summary

Thank you Timo for the great summary! It covers (almost) all the topics. Even though in the end we are not suggesting much changes to the current state of FLIP I think it is important to lay out all possible use cases so that we do not change the execution model every release. There is one additio

Re: [DISCUSS]FLIP-113: Support SQL and planner hints

Hi, Few comments from my side: 1. Regarding the motivation: I think the example with changing the update-mode is not a good one. In the long term this should be done with EMIT CHANGELOG (discussed in FLIP-105). Nitpicking: I would mention that it is rather for debugging/ad-hoc solution. I think

Re: [DISCUSS] FLIP-84 Feedback Summary

are few >>> user cases >>> in the feedback document which behavior is unclear now. >>> >>> regarding to "change the return value from `Iterable>> `Iterator>> I couldn't agree more with this change. Just as Dawid mentioned >>> "Th

Re: [VOTE] FLIP-95: New TableSource and TableSink interfaces

Generally +1 One slight concern I have is about the |SupportsProjectionPushDown.|I don't necessarily understand how can we express projections with TableSchema. It's unclear for me what happens when a type of a field changes, fields are in a different order, when types do not match. How do we expr

Re: Question about the ReadableConfigToConfigurationAdapter

Hi, Yes this is a bug that is tracked here: https://issues.apache.org/jira/browse/FLINK-16913. I am working on it right now. You should expect a fix very soon. Best, Dawid On 02/04/2020 17:07, Till Rohrmann wrote: > Hi Canbin, > > this looks indeed like a bug to me. I'm pulling in Dawid who wo

Re: [VOTE] FLIP-122: New Connector Property Keys for New Factory

+1 Best, Dawid On 02/04/2020 18:28, Timo Walther wrote: > +1 > > Thanks, > Timo > > On 02.04.20 17:22, Jark Wu wrote: >> Hi all, >> >> I would like to start the vote for FLIP-122 [1], which is discussed and >> reached a consensus in the discussion thread [2]. >> >> The vote will be open for at l

Re: [VOTE] FLIP-95: New TableSource and TableSink interfaces

leSource#Context#getKeys()` to represent nested >>>> structure of names. Data types, constraints, or computed columns are not >>>> necessary at those locations. >>>> >>>> We can also add utility methods for connectors to this helper class >>>> there to quickly

[DISCUSS] FLIP-124: Add open/close and Collector to (De)SerializationSchema

Hi devs, When working on improving the Table API/SQL connectors we faced a few shortcomings of the DeserializationSchema and SerializationSchema interfaces. Similar features were also mentioned by other users in the past. The shortcomings I would like to address with the FLIP include: * Emittin

[RESULT][VOTE] FLIP-110: Support LIKE clause in CREATE TABLE

Hi all, The voting time for FLIP-110 has passed. I'm closing the vote now. There were 5 +1 votes, 4 of which are binding: - Timo (binding) - Jingsong (binding) - Danny (non-binding) - Jark (binding) - Aljosha (binding) There were no disapproving votes. Thus, FLIP-110 has been accepted. T

Re: [VOTE] FLIP-84: Improve & Refactor API of TableEnvironment & Table

+1 Best, Dawid On 07/04/2020 07:44, godfrey he wrote: > Hi, Kurt > > yes. `TableEnvironement#executeSql` also could execute `SELECT` statement, > which is similar to `Table#execute`. > I add this to the document. > > Best, > Godfrey > > Kurt Young 于2020年4月7日周二 上午11:52写道： > >> +1 (binding) >> >>

Re: [DISCUSS] FLIP-124: Add open/close and Collector to (De)SerializationSchema

;>> >>> deserialize( >>> byte[] recordValue, >>> String partitionKey, >>> String seqNum, >>> long approxArrivalTimestamp, >>> String stream, >>>

Re: [ANNOUNCE] New Flink committer: Seth Wiesman

Congratulations Seth. Happy to have you in the community! Best, Dawid On 07/04/2020 08:43, Dian Fu wrote: > Congratulations! > >> 在 2020年4月7日，下午2:35，Konstantin Knauf 写道： >> >> Congratulations, Seth! Well deserved :) >> >> On Tue, Apr 7, 2020 at 8:33 AM Tzu-Li (Gordon) Tai >> wrote: >> >>> Hi e

Re: [ANNOUNCE] New Committers and PMC member

Thank you all for the support! Best, Dawid On 02/04/2020 04:33, godfrey he wrote: > Congratulations to all of you~ > > Best, > Godfrey > > Ismaël Mejía 于2020年4月2日周四 上午6:42写道： > >> Congrats everyone! >> >> On Thu, Apr 2, 2020 at 12:16 AM Rong Rong wrote: >>> Congratulations to all!!! >>> >>> --

Re: [VOTE] FLIP-113: Supports Dynamic Table Options for Flink SQL

+1, Best, Dawid On 10/04/2020 12:07, Kurt Young wrote: > +1 > > Best, > Kurt > > > On Fri, Apr 10, 2020 at 6:01 PM Jark Wu wrote: > >> +1 from my side (binding) >> >> Best, >> Jark >> >> On Fri, 10 Apr 2020 at 17:03, Timo Walther wrote: >> >>> +1 (binding) >>> >>> Thanks for the healthy discu

Re: [DISCUSS] FLIP-124: Add open/close and Collector to (De)SerializationSchema

lso required in our >> cases. I think it's also a common need for other users. >> >> In the this proposal, with more components added into the context, in the >> end we will find the serialization/deserialization schema is just another >> wrapper of ProcessFuncti

[VOTE] FLIP-124: Add open/close and Collector to (De)SerializationSchema

Hi all, I would like to start the vote for FLIP-124 [1], which is discussed and reached a consensus in the discussion thread [2]. The vote will be open until April 20th, unless there is an objection or not enough votes. Best, Dawid [1] https://cwiki.apache.org/confluence/pages/viewpage.action?

  1   2   3   4   5   6   7   8   9   10   >