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 column in the Scala DSL I think it's important to move those changes forward as it makes it easier to transition to the new type system (Java parser supports only the old type system stack for now) that we are working on for the past releases. Because the previous discussion thread was rather conclusive I want to start already with a vote. If you think we need another round of discussion, feel free to say so. The vote will last for at least 72 hours, following the consensus voting process. FLIP wiki: [1] https://cwiki.apache.org/confluence/display/FLINK/FLIP-55%3A+Introduction+of+a+Table+API+Java+Expression+DSL Discussion thread: https://lists.apache.org/thread.html/eb5e7b0579e5f1da1e9bf1ab4e4b86dba737946f0261d94d8c30521e@%3Cdev.flink.apache.org%3E signature.asc (849 bytes) Download Attachment |
+1 for this.
It will also help in making a TableEnvironment.fromElements() possible and reduces technical debt. One entry point of TypeInformation less in the API. Regards, Timo On 10.02.20 08:31, Dawid Wysakowicz wrote: > 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 column in the Scala DSL > > I think it's important to move those changes forward as it makes it > easier to transition to the new type system (Java parser supports only > the old type system stack for now) that we are working on for the past > releases. > > Because the previous discussion thread was rather conclusive I want to > start already with a vote. If you think we need another round of > discussion, feel free to say so. > > > The vote will last for at least 72 hours, following the consensus voting > process. > > FLIP wiki: > > [1] > https://cwiki.apache.org/confluence/display/FLINK/FLIP-55%3A+Introduction+of+a+Table+API+Java+Expression+DSL > > > Discussion thread: > > https://lists.apache.org/thread.html/eb5e7b0579e5f1da1e9bf1ab4e4b86dba737946f0261d94d8c30521e@%3Cdev.flink.apache.org%3E > > > > |
Hi Dawid,
Thanks for driving. - adding $ in scala api looks good to me. - Just a question, what should be expected 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 <[hidden email]> wrote: > +1 for this. > > It will also help in making a TableEnvironment.fromElements() possible > and reduces technical debt. One entry point of TypeInformation less in > the API. > > Regards, > Timo > > > On 10.02.20 08:31, Dawid Wysakowicz wrote: > > 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 column in the Scala DSL > > > > I think it's important to move those changes forward as it makes it > > easier to transition to the new type system (Java parser supports only > > the old type system stack for now) that we are working on for the past > > releases. > > > > Because the previous discussion thread was rather conclusive I want to > > start already with a vote. If you think we need another round of > > discussion, feel free to say so. > > > > > > The vote will last for at least 72 hours, following the consensus voting > > process. > > > > FLIP wiki: > > > > [1] > > > https://cwiki.apache.org/confluence/display/FLINK/FLIP-55%3A+Introduction+of+a+Table+API+Java+Expression+DSL > > > > > > Discussion thread: > > > > > https://lists.apache.org/thread.html/eb5e7b0579e5f1da1e9bf1ab4e4b86dba737946f0261d94d8c30521e@%3Cdev.flink.apache.org%3E > > > > > > > > > > -- Best, Jingsong Lee |
+1 for this.
I have some minor comments: - I'm +1 to use $ in both Java and Scala API. - I'm +1 to use lit(), Spark also provides lit() function to create a literal value. - Is it possible to have `isGreater` instead of `isGreaterThan` and `isGreaterOrEqual` instead of `isGreaterThanOrEqualTo` in BaseExpressions? Best, Jark On Tue, 11 Feb 2020 at 10:21, Jingsong Li <[hidden email]> wrote: > Hi Dawid, > > Thanks for driving. > > - adding $ in scala api looks good to me. > - Just a question, what should be expected 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 <[hidden email]> wrote: > > > +1 for this. > > > > It will also help in making a TableEnvironment.fromElements() possible > > and reduces technical debt. One entry point of TypeInformation less in > > the API. > > > > Regards, > > Timo > > > > > > On 10.02.20 08:31, Dawid Wysakowicz wrote: > > > 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 column in the Scala DSL > > > > > > I think it's important to move those changes forward as it makes it > > > easier to transition to the new type system (Java parser supports only > > > the old type system stack for now) that we are working on for the past > > > releases. > > > > > > Because the previous discussion thread was rather conclusive I want to > > > start already with a vote. If you think we need another round of > > > discussion, feel free to say so. > > > > > > > > > The vote will last for at least 72 hours, following the consensus > voting > > > process. > > > > > > FLIP wiki: > > > > > > [1] > > > > > > https://cwiki.apache.org/confluence/display/FLINK/FLIP-55%3A+Introduction+of+a+Table+API+Java+Expression+DSL > > > > > > > > > Discussion thread: > > > > > > > > > https://lists.apache.org/thread.html/eb5e7b0579e5f1da1e9bf1ab4e4b86dba737946f0261d94d8c30521e@%3Cdev.flink.apache.org%3E > > > > > > > > > > > > > > > > > > -- > Best, Jingsong Lee > |
Hi Dawid,
Thanks for driving this feature. The design looks very well for me overall. I have only one concern: $ is not allowed to be used in the identifier of Python and so we have to come out with another symbol when aligning this feature in the Python Table API. I noticed that there are also other options proposed in the discussion thread, e.g. ref, col, etc. I think it would be great if the proposed symbol could be supported in both the Java/Scala and Python Table API. What's your thoughts? Regards, Dian > 在 2020年2月11日,上午11:13,Jark Wu <[hidden email]> 写道: > > +1 for this. > > I have some minor comments: > - I'm +1 to use $ in both Java and Scala API. > - I'm +1 to use lit(), Spark also provides lit() function to create a > literal value. > - Is it possible to have `isGreater` instead of `isGreaterThan` and > `isGreaterOrEqual` instead of `isGreaterThanOrEqualTo` in BaseExpressions? > > Best, > Jark > > On Tue, 11 Feb 2020 at 10:21, Jingsong Li <[hidden email]> wrote: > >> Hi Dawid, >> >> Thanks for driving. >> >> - adding $ in scala api looks good to me. >> - Just a question, what should be expected 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 <[hidden email]> wrote: >> >>> +1 for this. >>> >>> It will also help in making a TableEnvironment.fromElements() possible >>> and reduces technical debt. One entry point of TypeInformation less in >>> the API. >>> >>> Regards, >>> Timo >>> >>> >>> On 10.02.20 08:31, Dawid Wysakowicz wrote: >>>> 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 column in the Scala DSL >>>> >>>> I think it's important to move those changes forward as it makes it >>>> easier to transition to the new type system (Java parser supports only >>>> the old type system stack for now) that we are working on for the past >>>> releases. >>>> >>>> Because the previous discussion thread was rather conclusive I want to >>>> start already with a vote. If you think we need another round of >>>> discussion, feel free to say so. >>>> >>>> >>>> The vote will last for at least 72 hours, following the consensus >> voting >>>> process. >>>> >>>> FLIP wiki: >>>> >>>> [1] >>>> >>> >> https://cwiki.apache.org/confluence/display/FLINK/FLIP-55%3A+Introduction+of+a+Table+API+Java+Expression+DSL >>>> >>>> >>>> Discussion thread: >>>> >>>> >>> >> https://lists.apache.org/thread.html/eb5e7b0579e5f1da1e9bf1ab4e4b86dba737946f0261d94d8c30521e@%3Cdev.flink.apache.org%3E >>>> >>>> >>>> >>>> >>> >>> >> >> -- >> Best, Jingsong Lee >> |
Hi,
To answer some of the questions: @Jingsong We use Objects in the java API to make it possible to use raw Objects without the need to wrap them in literals. If an expression is passed it is used as is. If anything else is used, it is assumed to be an literal and is wrapped into a literal. This way we can e.g. write $("f0").plus(1). @Jark I think it makes sense to shorten them, I will do it I hope people that already voted don't mind. @Dian That's a valid concern. I would not discard the '$' as a column expression for java and scala. I think once we introduce the expression DSL for python we can add another alias to java/scala. Personally I'd be in favor of col. On 11/02/2020 10:41, Dian Fu wrote: > Hi Dawid, > > Thanks for driving this feature. The design looks very well for me overall. > > I have only one concern: $ is not allowed to be used in the identifier of Python and so we have to come out with another symbol when aligning this feature in the Python Table API. I noticed that there are also other options proposed in the discussion thread, e.g. ref, col, etc. I think it would be great if the proposed symbol could be supported in both the Java/Scala and Python Table API. What's your thoughts? > > Regards, > Dian > >> 在 2020年2月11日,上午11:13,Jark Wu <[hidden email]> 写道: >> >> +1 for this. >> >> I have some minor comments: >> - I'm +1 to use $ in both Java and Scala API. >> - I'm +1 to use lit(), Spark also provides lit() function to create a >> literal value. >> - Is it possible to have `isGreater` instead of `isGreaterThan` and >> `isGreaterOrEqual` instead of `isGreaterThanOrEqualTo` in BaseExpressions? >> >> Best, >> Jark >> >> On Tue, 11 Feb 2020 at 10:21, Jingsong Li <[hidden email]> wrote: >> >>> Hi Dawid, >>> >>> Thanks for driving. >>> >>> - adding $ in scala api looks good to me. >>> - Just a question, what should be expected 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 <[hidden email]> wrote: >>> >>>> +1 for this. >>>> >>>> It will also help in making a TableEnvironment.fromElements() possible >>>> and reduces technical debt. One entry point of TypeInformation less in >>>> the API. >>>> >>>> Regards, >>>> Timo >>>> >>>> >>>> On 10.02.20 08:31, Dawid Wysakowicz wrote: >>>>> 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 column in the Scala DSL >>>>> >>>>> I think it's important to move those changes forward as it makes it >>>>> easier to transition to the new type system (Java parser supports only >>>>> the old type system stack for now) that we are working on for the past >>>>> releases. >>>>> >>>>> Because the previous discussion thread was rather conclusive I want to >>>>> start already with a vote. If you think we need another round of >>>>> discussion, feel free to say so. >>>>> >>>>> >>>>> The vote will last for at least 72 hours, following the consensus >>> voting >>>>> process. >>>>> >>>>> FLIP wiki: >>>>> >>>>> [1] >>>>> >>> https://cwiki.apache.org/confluence/display/FLINK/FLIP-55%3A+Introduction+of+a+Table+API+Java+Expression+DSL >>>>> >>>>> Discussion thread: >>>>> >>>>> >>> https://lists.apache.org/thread.html/eb5e7b0579e5f1da1e9bf1ab4e4b86dba737946f0261d94d8c30521e@%3Cdev.flink.apache.org%3E >>>>> >>>>> >>>>> >>>> >>> -- >>> Best, Jingsong Lee >>> signature.asc (849 bytes) Download Attachment |
Thanks Dawid for your explanation,
+1 for vote. So I am big +1 to accepting java.lang.Object in 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 <[hidden email]> wrote: > Hi, > > To answer some of the questions: > > @Jingsong We use Objects in the java API to make it possible to use raw > Objects without the need to wrap them in literals. If an expression is > passed it is used as is. If anything else is used, it is assumed to be > an literal and is wrapped into a literal. This way we can e.g. write > $("f0").plus(1). > > @Jark I think it makes sense to shorten them, I will do it I hope people > that already voted don't mind. > > @Dian That's a valid concern. I would not discard the '$' as a column > expression for java and scala. I think once we introduce the expression > DSL for python we can add another alias to java/scala. Personally I'd be > in favor of col. > > On 11/02/2020 10:41, Dian Fu wrote: > > Hi Dawid, > > > > Thanks for driving this feature. The design looks very well for me > overall. > > > > I have only one concern: $ is not allowed to be used in the identifier > of Python and so we have to come out with another symbol when aligning this > feature in the Python Table API. I noticed that there are also other > options proposed in the discussion thread, e.g. ref, col, etc. I think it > would be great if the proposed symbol could be supported in both the > Java/Scala and Python Table API. What's your thoughts? > > > > Regards, > > Dian > > > >> 在 2020年2月11日,上午11:13,Jark Wu <[hidden email]> 写道: > >> > >> +1 for this. > >> > >> I have some minor comments: > >> - I'm +1 to use $ in both Java and Scala API. > >> - I'm +1 to use lit(), Spark also provides lit() function to create a > >> literal value. > >> - Is it possible to have `isGreater` instead of `isGreaterThan` and > >> `isGreaterOrEqual` instead of `isGreaterThanOrEqualTo` in > BaseExpressions? > >> > >> Best, > >> Jark > >> > >> On Tue, 11 Feb 2020 at 10:21, Jingsong Li <[hidden email]> > wrote: > >> > >>> Hi Dawid, > >>> > >>> Thanks for driving. > >>> > >>> - adding $ in scala api looks good to me. > >>> - Just a question, what should be expected 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 <[hidden email]> > wrote: > >>> > >>>> +1 for this. > >>>> > >>>> It will also help in making a TableEnvironment.fromElements() possible > >>>> and reduces technical debt. One entry point of TypeInformation less in > >>>> the API. > >>>> > >>>> Regards, > >>>> Timo > >>>> > >>>> > >>>> On 10.02.20 08:31, Dawid Wysakowicz wrote: > >>>>> 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 column in the Scala DSL > >>>>> > >>>>> I think it's important to move those changes forward as it makes it > >>>>> easier to transition to the new type system (Java parser supports > only > >>>>> the old type system stack for now) that we are working on for the > past > >>>>> releases. > >>>>> > >>>>> Because the previous discussion thread was rather conclusive I want > to > >>>>> start already with a vote. If you think we need another round of > >>>>> discussion, feel free to say so. > >>>>> > >>>>> > >>>>> The vote will last for at least 72 hours, following the consensus > >>> voting > >>>>> process. > >>>>> > >>>>> FLIP wiki: > >>>>> > >>>>> [1] > >>>>> > >>> > https://cwiki.apache.org/confluence/display/FLINK/FLIP-55%3A+Introduction+of+a+Table+API+Java+Expression+DSL > >>>>> > >>>>> Discussion thread: > >>>>> > >>>>> > >>> > https://lists.apache.org/thread.html/eb5e7b0579e5f1da1e9bf1ab4e4b86dba737946f0261d94d8c30521e@%3Cdev.flink.apache.org%3E > >>>>> > >>>>> > >>>>> > >>>> > >>> -- > >>> Best, Jingsong Lee > >>> > > -- Best, Jingsong Lee |
+1
Best, Aljoscha On 11.02.20 11:17, Jingsong Li wrote: > Thanks Dawid for your explanation, > > +1 for vote. > > So I am big +1 to accepting java.lang.Object in 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 <[hidden email]> > wrote: > >> Hi, >> >> To answer some of the questions: >> >> @Jingsong We use Objects in the java API to make it possible to use raw >> Objects without the need to wrap them in literals. If an expression is >> passed it is used as is. If anything else is used, it is assumed to be >> an literal and is wrapped into a literal. This way we can e.g. write >> $("f0").plus(1). >> >> @Jark I think it makes sense to shorten them, I will do it I hope people >> that already voted don't mind. >> >> @Dian That's a valid concern. I would not discard the '$' as a column >> expression for java and scala. I think once we introduce the expression >> DSL for python we can add another alias to java/scala. Personally I'd be >> in favor of col. >> >> On 11/02/2020 10:41, Dian Fu wrote: >>> Hi Dawid, >>> >>> Thanks for driving this feature. The design looks very well for me >> overall. >>> >>> I have only one concern: $ is not allowed to be used in the identifier >> of Python and so we have to come out with another symbol when aligning this >> feature in the Python Table API. I noticed that there are also other >> options proposed in the discussion thread, e.g. ref, col, etc. I think it >> would be great if the proposed symbol could be supported in both the >> Java/Scala and Python Table API. What's your thoughts? >>> >>> Regards, >>> Dian >>> >>>> 在 2020年2月11日,上午11:13,Jark Wu <[hidden email]> 写道: >>>> >>>> +1 for this. >>>> >>>> I have some minor comments: >>>> - I'm +1 to use $ in both Java and Scala API. >>>> - I'm +1 to use lit(), Spark also provides lit() function to create a >>>> literal value. >>>> - Is it possible to have `isGreater` instead of `isGreaterThan` and >>>> `isGreaterOrEqual` instead of `isGreaterThanOrEqualTo` in >> BaseExpressions? >>>> >>>> Best, >>>> Jark >>>> >>>> On Tue, 11 Feb 2020 at 10:21, Jingsong Li <[hidden email]> >> wrote: >>>> >>>>> Hi Dawid, >>>>> >>>>> Thanks for driving. >>>>> >>>>> - adding $ in scala api looks good to me. >>>>> - Just a question, what should be expected 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 <[hidden email]> >> wrote: >>>>> >>>>>> +1 for this. >>>>>> >>>>>> It will also help in making a TableEnvironment.fromElements() possible >>>>>> and reduces technical debt. One entry point of TypeInformation less in >>>>>> the API. >>>>>> >>>>>> Regards, >>>>>> Timo >>>>>> >>>>>> >>>>>> On 10.02.20 08:31, Dawid Wysakowicz wrote: >>>>>>> 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 column in the Scala DSL >>>>>>> >>>>>>> I think it's important to move those changes forward as it makes it >>>>>>> easier to transition to the new type system (Java parser supports >> only >>>>>>> the old type system stack for now) that we are working on for the >> past >>>>>>> releases. >>>>>>> >>>>>>> Because the previous discussion thread was rather conclusive I want >> to >>>>>>> start already with a vote. If you think we need another round of >>>>>>> discussion, feel free to say so. >>>>>>> >>>>>>> >>>>>>> The vote will last for at least 72 hours, following the consensus >>>>> voting >>>>>>> process. >>>>>>> >>>>>>> FLIP wiki: >>>>>>> >>>>>>> [1] >>>>>>> >>>>> >> https://cwiki.apache.org/confluence/display/FLINK/FLIP-55%3A+Introduction+of+a+Table+API+Java+Expression+DSL >>>>>>> >>>>>>> Discussion thread: >>>>>>> >>>>>>> >>>>> >> https://lists.apache.org/thread.html/eb5e7b0579e5f1da1e9bf1ab4e4b86dba737946f0261d94d8c30521e@%3Cdev.flink.apache.org%3E >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> -- >>>>> Best, Jingsong Lee >>>>> >> >> > |
Hi Dawid,
Thanks for your reply. I'm also in favor of "col" as a column expression in the Python Table API. Regarding to use "$" in the Java/Scala Table API, I'm fine with it. So +1 from my side. Thanks, Dian > 在 2020年2月11日,下午9:48,Aljoscha Krettek <[hidden email]> 写道: > > +1 > > Best, > Aljoscha > > On 11.02.20 11:17, Jingsong Li wrote: >> Thanks Dawid for your explanation, >> +1 for vote. >> So I am big +1 to accepting java.lang.Object in 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 <[hidden email]> >> wrote: >>> Hi, >>> >>> To answer some of the questions: >>> >>> @Jingsong We use Objects in the java API to make it possible to use raw >>> Objects without the need to wrap them in literals. If an expression is >>> passed it is used as is. If anything else is used, it is assumed to be >>> an literal and is wrapped into a literal. This way we can e.g. write >>> $("f0").plus(1). >>> >>> @Jark I think it makes sense to shorten them, I will do it I hope people >>> that already voted don't mind. >>> >>> @Dian That's a valid concern. I would not discard the '$' as a column >>> expression for java and scala. I think once we introduce the expression >>> DSL for python we can add another alias to java/scala. Personally I'd be >>> in favor of col. >>> >>> On 11/02/2020 10:41, Dian Fu wrote: >>>> Hi Dawid, >>>> >>>> Thanks for driving this feature. The design looks very well for me >>> overall. >>>> >>>> I have only one concern: $ is not allowed to be used in the identifier >>> of Python and so we have to come out with another symbol when aligning this >>> feature in the Python Table API. I noticed that there are also other >>> options proposed in the discussion thread, e.g. ref, col, etc. I think it >>> would be great if the proposed symbol could be supported in both the >>> Java/Scala and Python Table API. What's your thoughts? >>>> >>>> Regards, >>>> Dian >>>> >>>>> 在 2020年2月11日,上午11:13,Jark Wu <[hidden email]> 写道: >>>>> >>>>> +1 for this. >>>>> >>>>> I have some minor comments: >>>>> - I'm +1 to use $ in both Java and Scala API. >>>>> - I'm +1 to use lit(), Spark also provides lit() function to create a >>>>> literal value. >>>>> - Is it possible to have `isGreater` instead of `isGreaterThan` and >>>>> `isGreaterOrEqual` instead of `isGreaterThanOrEqualTo` in >>> BaseExpressions? >>>>> >>>>> Best, >>>>> Jark >>>>> >>>>> On Tue, 11 Feb 2020 at 10:21, Jingsong Li <[hidden email]> >>> wrote: >>>>> >>>>>> Hi Dawid, >>>>>> >>>>>> Thanks for driving. >>>>>> >>>>>> - adding $ in scala api looks good to me. >>>>>> - Just a question, what should be expected 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 <[hidden email]> >>> wrote: >>>>>> >>>>>>> +1 for this. >>>>>>> >>>>>>> It will also help in making a TableEnvironment.fromElements() possible >>>>>>> and reduces technical debt. One entry point of TypeInformation less in >>>>>>> the API. >>>>>>> >>>>>>> Regards, >>>>>>> Timo >>>>>>> >>>>>>> >>>>>>> On 10.02.20 08:31, Dawid Wysakowicz wrote: >>>>>>>> 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 column in the Scala DSL >>>>>>>> >>>>>>>> I think it's important to move those changes forward as it makes it >>>>>>>> easier to transition to the new type system (Java parser supports >>> only >>>>>>>> the old type system stack for now) that we are working on for the >>> past >>>>>>>> releases. >>>>>>>> >>>>>>>> Because the previous discussion thread was rather conclusive I want >>> to >>>>>>>> start already with a vote. If you think we need another round of >>>>>>>> discussion, feel free to say so. >>>>>>>> >>>>>>>> >>>>>>>> The vote will last for at least 72 hours, following the consensus >>>>>> voting >>>>>>>> process. >>>>>>>> >>>>>>>> FLIP wiki: >>>>>>>> >>>>>>>> [1] >>>>>>>> >>>>>> >>> https://cwiki.apache.org/confluence/display/FLINK/FLIP-55%3A+Introduction+of+a+Table+API+Java+Expression+DSL >>>>>>>> >>>>>>>> Discussion thread: >>>>>>>> >>>>>>>> >>>>>> >>> https://lists.apache.org/thread.html/eb5e7b0579e5f1da1e9bf1ab4e4b86dba737946f0261d94d8c30521e@%3Cdev.flink.apache.org%3E >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> -- >>>>>> Best, Jingsong Lee >>>>>> >>> >>> |
Thanks all for the votes.
So far, we have - 3 binding +1 votes (Timo, Jark, Aljoscha) - 2 non-binding +1 votes (Jingsong, Dian) - No -1 votes The voting time has past and there is enough +1 votes to consider the FLIP-55 approved. Thank you all. Best, Dawid On 12/02/2020 06:21, Dian Fu wrote: > Hi Dawid, > > Thanks for your reply. I'm also in favor of "col" as a column expression in the Python Table API. Regarding to use "$" in the Java/Scala Table API, I'm fine with it. So +1 from my side. > > Thanks, > Dian > >> 在 2020年2月11日,下午9:48,Aljoscha Krettek <[hidden email]> 写道: >> >> +1 >> >> Best, >> Aljoscha >> >> On 11.02.20 11:17, Jingsong Li wrote: >>> Thanks Dawid for your explanation, >>> +1 for vote. >>> So I am big +1 to accepting java.lang.Object in 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 <[hidden email]> >>> wrote: >>>> Hi, >>>> >>>> To answer some of the questions: >>>> >>>> @Jingsong We use Objects in the java API to make it possible to use raw >>>> Objects without the need to wrap them in literals. If an expression is >>>> passed it is used as is. If anything else is used, it is assumed to be >>>> an literal and is wrapped into a literal. This way we can e.g. write >>>> $("f0").plus(1). >>>> >>>> @Jark I think it makes sense to shorten them, I will do it I hope people >>>> that already voted don't mind. >>>> >>>> @Dian That's a valid concern. I would not discard the '$' as a column >>>> expression for java and scala. I think once we introduce the expression >>>> DSL for python we can add another alias to java/scala. Personally I'd be >>>> in favor of col. >>>> >>>> On 11/02/2020 10:41, Dian Fu wrote: >>>>> Hi Dawid, >>>>> >>>>> Thanks for driving this feature. The design looks very well for me >>>> overall. >>>>> I have only one concern: $ is not allowed to be used in the identifier >>>> of Python and so we have to come out with another symbol when aligning this >>>> feature in the Python Table API. I noticed that there are also other >>>> options proposed in the discussion thread, e.g. ref, col, etc. I think it >>>> would be great if the proposed symbol could be supported in both the >>>> Java/Scala and Python Table API. What's your thoughts? >>>>> Regards, >>>>> Dian >>>>> >>>>>> 在 2020年2月11日,上午11:13,Jark Wu <[hidden email]> 写道: >>>>>> >>>>>> +1 for this. >>>>>> >>>>>> I have some minor comments: >>>>>> - I'm +1 to use $ in both Java and Scala API. >>>>>> - I'm +1 to use lit(), Spark also provides lit() function to create a >>>>>> literal value. >>>>>> - Is it possible to have `isGreater` instead of `isGreaterThan` and >>>>>> `isGreaterOrEqual` instead of `isGreaterThanOrEqualTo` in >>>> BaseExpressions? >>>>>> Best, >>>>>> Jark >>>>>> >>>>>> On Tue, 11 Feb 2020 at 10:21, Jingsong Li <[hidden email]> >>>> wrote: >>>>>>> Hi Dawid, >>>>>>> >>>>>>> Thanks for driving. >>>>>>> >>>>>>> - adding $ in scala api looks good to me. >>>>>>> - Just a question, what should be expected 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 <[hidden email]> >>>> wrote: >>>>>>>> +1 for this. >>>>>>>> >>>>>>>> It will also help in making a TableEnvironment.fromElements() possible >>>>>>>> and reduces technical debt. One entry point of TypeInformation less in >>>>>>>> the API. >>>>>>>> >>>>>>>> Regards, >>>>>>>> Timo >>>>>>>> >>>>>>>> >>>>>>>> On 10.02.20 08:31, Dawid Wysakowicz wrote: >>>>>>>>> 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 column in the Scala DSL >>>>>>>>> >>>>>>>>> I think it's important to move those changes forward as it makes it >>>>>>>>> easier to transition to the new type system (Java parser supports >>>> only >>>>>>>>> the old type system stack for now) that we are working on for the >>>> past >>>>>>>>> releases. >>>>>>>>> >>>>>>>>> Because the previous discussion thread was rather conclusive I want >>>> to >>>>>>>>> start already with a vote. If you think we need another round of >>>>>>>>> discussion, feel free to say so. >>>>>>>>> >>>>>>>>> >>>>>>>>> The vote will last for at least 72 hours, following the consensus >>>>>>> voting >>>>>>>>> process. >>>>>>>>> >>>>>>>>> FLIP wiki: >>>>>>>>> >>>>>>>>> [1] >>>>>>>>> >>>> https://cwiki.apache.org/confluence/display/FLINK/FLIP-55%3A+Introduction+of+a+Table+API+Java+Expression+DSL >>>>>>>>> Discussion thread: >>>>>>>>> >>>>>>>>> >>>> https://lists.apache.org/thread.html/eb5e7b0579e5f1da1e9bf1ab4e4b86dba737946f0261d94d8c30521e@%3Cdev.flink.apache.org%3E >>>>>>>>> >>>>>>>>> >>>>>>> -- >>>>>>> Best, Jingsong Lee >>>>>>> >>>> signature.asc (849 bytes) Download Attachment |
Free forum by Nabble | Edit this page |