Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
Drill >> mail # dev >> DrQL grammar and parser


Copy link to this message
-
Re: DrQL grammar and parser


Sent from my iPhone

On Aug 26, 2012, at 3:21 PM, Camuel Gilyadov <[EMAIL PROTECTED]> wrote:

> On Mon, Aug 27, 2012 at 12:22 AM, Ted Dunning <[EMAIL PROTECTED]> wrote:
>
>> Camuel,
>>
>> Do you have a grammar test suite that demonstrates the range of
>> expressions?
>>
>
> I don't have an exhaustive one. But with OpenDremel I tested it with all
> sample queries given in the BQL manual and then adding my own for various
> cases. I can do similar thing here as well as develop grammar unit tests
> (with ANTLR's gunit).
>
>
>>
>> Also, I believe that some have a goal to use additional languages besides
>> SQL like languages.  A limited version of pig, for instance, would be very
>> interesting.  To do this, it will be important to have a logical plan
>> structure that is common for different syntaxes and is not limited to the
>> idiosyncracies of any particular syntax.
>>
>> How do you think that should be handled?  Do you have an idea for a logical
>> plan structure?
>>
>
> Yes I have, but I afraid it is a radical idea. I think queries must be
> directly compiled into generic C source code. That way in worst case, a
> completely separate compiler could be developed for some exotic query
> language and backend could be still reused. On other extreme, dialects
> could be handled in the grammar itself yielding same AST so frontend code
> should not even be aware.Between these two extremes two different grammars
> should be used, both yielding object models which could then handled by
> same code generator (so code generator is reused). Not to say that this
> approach simplifies the backend and it is most tricky part to implement as
> it must be scaled and secured and outlives single query or query session.
>
> I think an attempt to design a logical query language expressive enough to
> cover many existing and future query languages would not be all that easy
> going...
>
>
>>
>> On Sun, Aug 26, 2012 at 4:11 PM, Camuel Gilyadov <[EMAIL PROTECTED]> wrote:
>>
>>> I've written and attached ANTLR grammar for DrQL which I assume is same
>> as
>>> BigQuery language described in Query Reference on BigQuery website. This
>>> grammar includes AST production rules.
>>>
>>>
>>>
>>
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB