You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flink.apache.org by Dawid Wysakowicz <dw...@apache.org> on 2020/02/10 07:31:41 UTC

[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 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





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

Posted by Dawid Wysakowicz <dw...@apache.org>.
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 <al...@apache.org> 写道:
>>
>> +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 <dw...@apache.org>
>>> 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 <im...@gmail.com> 写道:
>>>>>>
>>>>>> +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 <ji...@gmail.com>
>>>> 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 <tw...@apache.org>
>>>> 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
>>>>>>>
>>>>


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

Posted by Dian Fu <di...@gmail.com>.
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 <al...@apache.org> 写道:
> 
> +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 <dw...@apache.org>
>> 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 <im...@gmail.com> 写道:
>>>>> 
>>>>> +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 <ji...@gmail.com>
>>> 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 <tw...@apache.org>
>>> 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
>>>>>> 
>>> 
>>> 


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

Posted by Aljoscha Krettek <al...@apache.org>.
+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 <dw...@apache.org>
> 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 <im...@gmail.com> 写道:
>>>>
>>>> +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 <ji...@gmail.com>
>> 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 <tw...@apache.org>
>> 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
>>>>>
>>
>>
> 

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

Posted by Jingsong Li <ji...@gmail.com>.
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 <dw...@apache.org>
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 <im...@gmail.com> 写道:
> >>
> >> +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 <ji...@gmail.com>
> 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 <tw...@apache.org>
> 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

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

Posted by Dawid Wysakowicz <dw...@apache.org>.
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 <im...@gmail.com> 写道:
>>
>> +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 <ji...@gmail.com> 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 <tw...@apache.org> 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
>>>


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

Posted by Dian Fu <di...@gmail.com>.
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 <im...@gmail.com> 写道:
> 
> +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 <ji...@gmail.com> 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 <tw...@apache.org> 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
>> 


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

Posted by Jark Wu <im...@gmail.com>.
+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 <ji...@gmail.com> 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 <tw...@apache.org> 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
>

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

Posted by Jingsong Li <ji...@gmail.com>.
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 <tw...@apache.org> 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

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

Posted by Timo Walther <tw...@apache.org>.
+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
> 
> 
> 
>