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 >
