The translation is done in multiple stages. 1. Parsing (syntax check) 2. Validation (semantic check) 3. Query optimization (rule and cost based) 4. Generation of physical plan, incl. code generation (DataStream program)
The final translation happens in the DataStream nodes, e.g., DataStreamCalc [1]. I'd recommend to import the source code and to debug the translation process. I recently gave a talk about the high-level translation process [2]. Best, Fabian [1] https://github.com/apache/flink/blob/master/flink-libraries/flink-table/src/main/scala/org/apache/flink/api/table/plan/nodes/datastream/DataStreamCalc.scala [2] http://www.slideshare.net/fhueske/taking-a-look-under-hood-of-apache-flinks-relational-apis 2016-10-17 18:42 GMT+02:00 PedroMrChaves <pedro.mr.cha...@gmail.com>: > Thank you for the response. > > I'm not understanding where does something like this, > > /SELECT * WHERE action='denied' / > > gets translated to something similar in the Flink Stream API, > > /filter.(new FilterFunction<Event>() { > public boolean filter(Event event) { > return event.action.equals("denied"); > } > });/ > > or if that happens at all. My idea was to extend the library to support > other unsupported > calls like (TUMBLE -> timeWindow) but it's probably more complex than what > I'm thinking. > > Regards. > > > > > -- > View this message in context: http://apache-flink-user- > mailing-list-archive.2336050.n4.nabble.com/Flink-SQL- > Stream-Parser-based-on-calcite-tp9592p9596.html > Sent from the Apache Flink User Mailing List archive. mailing list archive > at Nabble.com. >
