TImo,
While it's not exactly pretty, I don't mind the $("field") construct.
It's not particularly surprising. The v() method troubles me more; it
looks mysterious. I think we would do better to have something more
explicit. val() isn't much better -- val("foo") could be interpreted
to mean the value of the "foo" column, or a literal string.
David
On Tue, Aug 27, 2019 at 5:45 PM Timo Walther <twal...@apache.org> wrote:
>
> Hi David,
>
> thanks for your feedback. With the current design, the DSL would be free
> of any ambiguity but it is definitely more verbose esp. around defining
> values.
>
> I would be happy about further suggestions that make the DSL more
> readable. I'm also not sure if we go for `$()` and `v()` instead of more
> readable `ref()` and `val()`. This could maybe make it look less
> "alien", what do you think?
>
> Some people mentioned to overload certain methods for accepting values
> or column names. E.g. `$("field").isEqual("str")` but then string values
> could be confused with column names.
>
> Thanks,
> Timo
>
> On 27.08.19 17:34, David Anderson wrote:
> > In general I'm in favor of anything that is going to make the Table
> > API easier to learn and more predictable in its behavior. This
> > proposal kind of falls in the middle. As someone who has spent hours
> > in the crevices between the various flavors of the current
> > implementations, I certainly view keeping the various APIs and DSLs
> > more in sync, and making them less buggy, as highly desirable.
> >
> > On the other hand, some of the details in the proposal do make the
> > resulting user code less pretty and less approachable than the current
> > Java DSL. In a training context it will be easy to teach, but I wonder
> > if we can find a way to make it look less alien at first glance.
> >
> > David
> >
> > On Wed, Aug 21, 2019 at 1:33 PM Timo Walther <twal...@apache.org> wrote:
> >> Hi everyone,
> >>
> >> some of you might remember the discussion I started end of March [1]
> >> about introducing a new Java DSL for Table API that is not embedded in a
> >> string.
> >>
> >> In particular, it solves the following issues:
> >>
> >> - No possibility of deprecating functions
> >>
> >> - Missing documentation for users
> >>
> >> - Missing auto-completion for users
> >>
> >> - Need to port the ExpressionParser from Scala to Java
> >>
> >> - Scala symbols are deprecated! A Java DSL can also enable the Scala DSL
> >> one.
> >>
> >> Due to shift of priorities, we could not work on it in Flink 1.9 but the
> >> feedback at that time was positive and we should aim for 1.10 to
> >> simplify the API with this change.
> >>
> >> We propose the following FLIP-55:
> >>
> >> https://docs.google.com/document/d/1CfaaD3j8APJDKwzIT4YsX7QD2huKTB4xlA3vnMUFJmA/edit?usp=sharing
> >> <https://docs.google.com/document/d/1CfaaD3j8APJDKwzIT4YsX7QD2huKTB4xlA3vnMUFJmA/edit#heading=h.jn04bfolpim0>
> >>
> >> Thanks for any feedback,
> >>
> >> Timo
> >>
> >> [1]
> >> https://lists.apache.org/thread.html/e6f31d7fa53890b91be0991c2da64556a91ef0fc9ab3ffa889dacc23@%3Cdev.flink.apache.org%3E
> >>
>
