Re: [DISCUSS] ANTLR4 parse template for Calcite ?
It is not using ANTLR. Since our goal is specifically to support parsing and manipulation of SQL in the frontend, we use https://sap.github.io/chevrotain/docs/ . We're quite happy with that. We have some pretty big ANTLR grammars for other (non-SQL) use cases and this approach definitely feels more lightweight. On Thu, Aug 22, 2019 at 12:22 PM Danny Chan wrote: > Create ！ Do you have the ANTLR.g4 file that can be shared ? > > Best, > Danny Chan > 在 2019年8月22日 +0800 PM5:45，Michael Franzkowiak ，写道： > > Danny, what is your web / frontend use case exactly? > > We've started to create some frontend helpers which you can find at > > https://github.com/contiamo/rhombic . It's all in a very early state but > > we'll likely spend some more time on it in the next months. Parsing is > here > > https://github.com/contiamo/rhombic/blob/master/src/SqlParser.ts . > > > > On Thu, Aug 22, 2019 at 11:38 AM Muhammad Gelbana > > wrote: > > > > > I once needed to fix this issue [1] but the fix was rejected because it > > > introduced worse performance than it ideally should. As mentioned in > the > > > comments, the current approach followed in the current parser is the > reason > > > for that. I mean if we designed the grammar differently, we could've > had > > > fixed the linked issue a long time ago as Julian already attempted to > fix > > > it. > > > > > > Having that said, we might go with *antlr* only to have that "better" > > > approach for our parsers. We don't have to dump our current parser of > > > course as *antlr* can be optionally activated. > > > > > > [1] https://issues.apache.org/jira/browse/CALCITE-35 > > > > > > Thanks, > > > Gelbana > > > > > > > > > On Thu, Aug 22, 2019 at 10:05 AM Danny Chan > wrote: > > > > > > > Thanks, Julian. > > > > > > > > I agree this would be a huge work, but I have to do this, I’m just > > > > wondering if any fellows here have the similar requests. > > > > > > > > Best, > > > > Danny Chan > > > > 在 2019年8月22日 +0800 PM2:15，Julian Hyde ，写道： > > > > > ANTLR isn’t significantly better than, or worse than, JavaCC, but > it’s > > > > different. So translating to ANTLR would be a rewrite, and would be a > > > HUGE > > > > amount of work. > > > > > > > > > > > > > > > > > > > > > On Aug 21, 2019, at 8:01 PM, Danny Chan > > > wrote: > > > > > > > > > > > > Now some of our fellows want to do the syntax promote in the WEB > > > page, > > > > and they what a parser in the front-page; The ANTLR4 can generate JS > > > parser > > > > directly but JAVACC couldn’t. > > > > > > > > > > > > So I’m wondering do you have the similar requests ? And do you > think > > > > there is necessity to support ANTLR4 g4 file in Calcite ? > > > > > > > > > > > > > > > > > > Best, > > > > > > Danny Chan > > > > > > > > > > > > > > > > >
Re: [DISCUSS] ANTLR4 parse template for Calcite ?
Danny, what is your web / frontend use case exactly? We've started to create some frontend helpers which you can find at https://github.com/contiamo/rhombic . It's all in a very early state but we'll likely spend some more time on it in the next months. Parsing is here https://github.com/contiamo/rhombic/blob/master/src/SqlParser.ts . On Thu, Aug 22, 2019 at 11:38 AM Muhammad Gelbana wrote: > I once needed to fix this issue [1] but the fix was rejected because it > introduced worse performance than it ideally should. As mentioned in the > comments, the current approach followed in the current parser is the reason > for that. I mean if we designed the grammar differently, we could've had > fixed the linked issue a long time ago as Julian already attempted to fix > it. > > Having that said, we might go with *antlr* only to have that "better" > approach for our parsers. We don't have to dump our current parser of > course as *antlr* can be optionally activated. > > [1] https://issues.apache.org/jira/browse/CALCITE-35 > > Thanks, > Gelbana > > > On Thu, Aug 22, 2019 at 10:05 AM Danny Chan wrote: > > > Thanks, Julian. > > > > I agree this would be a huge work, but I have to do this, I’m just > > wondering if any fellows here have the similar requests. > > > > Best, > > Danny Chan > > 在 2019年8月22日 +0800 PM2:15，Julian Hyde ，写道： > > > ANTLR isn’t significantly better than, or worse than, JavaCC, but it’s > > different. So translating to ANTLR would be a rewrite, and would be a > HUGE > > amount of work. > > > > > > > > > > > > > On Aug 21, 2019, at 8:01 PM, Danny Chan > wrote: > > > > > > > > Now some of our fellows want to do the syntax promote in the WEB > page, > > and they what a parser in the front-page; The ANTLR4 can generate JS > parser > > directly but JAVACC couldn’t. > > > > > > > > So I’m wondering do you have the similar requests ? And do you think > > there is necessity to support ANTLR4 g4 file in Calcite ? > > > > > > > > > > > > Best, > > > > Danny Chan > > > > > > -- *Michael Franzkowiak* Managing Director *Contiamo* - the fastest way from data to results Address: Stresemannstraße 123 | 10963 Berlin | Germany <https://goo.gl/maps/xK1VtGifRHw> Web: www.contiamo.com Company Information (EN): Contiamo GmbH, Registered office of the company: Berlin HR Berlin-Charlottenburg, HRB no. 156569 Managing directors: Michael Franzkowiak, Lucia Hegenbartová Unternehmensinformationen (DE): Contiamo GmbH, Sitz der Gesellschaft: Berlin HR Berlin-Charlottenburg, HRB Nr. 156569 Geschäftsführer: Michael Franzkowiak, Lucia Hegenbartová
Specifying a table of a subschema in RelBuilder
Hi all, we have a (very basic) custom query DSL for OLAP type queries and are investigating whether we can replace and improve on our current execution engine using calcite. We believe using the RelBuilder would be a much nicer way to go from our custom query format to actual DB queries (while offering many potential benefits - planning process etc. - in the future). That said, we’ve run into a small issue: the “scan” method only accepts a String as a table identifier, meaning that we can’t specify a table of a sub schema (“db1”.”my_table”). Since RelOptSchema.getTableForMember accepts a list of Strings for this case we’re wondering whether a) there is a reason for only accepting a String (there is a comment in RelOptSchema.getTableForMember stating that “names.length is only greater than 1 for queries originating from JDBC”) b) scan could be overloaded to accept a List of Strings as well (in which case we’re happy to make that change) Cheers, Michael
