Re: [DISCUSS] ANTLR4 parse template for Calcite ?

2019-08-22 Thread Michael Franzkowiak
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 ?

2019-08-22 Thread 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
> > >
> >
>


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

2016-05-18 Thread Michael Franzkowiak
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