db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (DERBY-6385) Make it possible to plug alternative parsers into Derby.
Date Mon, 21 Oct 2013 20:39:42 GMT

     [ https://issues.apache.org/jira/browse/DERBY-6385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Rick Hillegas updated DERBY-6385:

    Attachment: plugableParser.diff

Attaching plugableParser.diff. This patch is a proof-of-concept for how you can extend SQLParser
in order to add statements to the existing grammar.  The goal is to make it easy to write
lightweight extensions to the current grammar and not have to create an enormous, standalone
javacc grammar. However, this approach could be used for plugging in large grammars for big
optional features.

There is already an existing interface for javacc parsers, which Derby understands: org.apache.derby.iapi.sql.compile.Parser.
I have not touched this interface. We may want to consider changing this interface later on,

This patch does the following:

1) Adds a new Parser implementation (DummyParser) which extends the current grammar by adding
one new statement: CREATE UNIQUE AGGREGATE. This statement doesn't actually do anything other
than create a DummyStatementNode. That node, in turn, raises an exception at bind() time.
This optional Parser by itself weighs 3.5K.

2) Makes a couple fields and methods public in sqlgrammar.jj so that they can be referenced
by the new Parser implementation.

3) Changes the existing Parser implementation (ParserImpl) to instantiate a DummyParser if
the statement can't be digested by the default grammar.

After applying these changes, the following script exercises it:

connect 'jdbc:derby:memory:db;create=true';

-- gets past the DummyParser but raises an error at bind() time
create unique aggregate app.foo;

-- unparseble
blah blah blah;


Touches the following files:


A       java/engine/org/apache/derby/impl/sql/compile/DummyStatementNode.java

Simple StatementNode which raises an unimplemented feature exception at bind() time.


M       java/engine/org/apache/derby/impl/sql/compile/sqlgrammar.jj

Made the following changes:

a) changed the protection on the ContextManager field and the initStatement() method.

b) added a protected method (consume_token()) to expose the behavior of the private jj_consume_token()
method generated by javacc.


A       java/engine/org/apache/derby/impl/sql/compile/DummyParser.java

New Parser implementation which extends the current grammar, adding a CREATE UNIQUE AGGREGATE
statement. I have not prototyped anything fancy like adding new keywords. If you extend the
current grammar like this, then you will want to re-compile your extended grammar for each
Derby release to make sure that your code understands the current values of the Derby keyword

To construct this class, I put the following production at the end of sqlgrammar.jj, then
built the grammar, then put the production's generated code into DummyParser.java. You can
imagine writing a build tool which takes a file of grammar extensions and mechanically generates
something like DummyParser.java:

uniqueAggregateDefinition() throws StandardException :
	TableName aggregateName;
		<CREATE> <UNIQUE> <AGGREGATE> aggregateName = qualifiedName(Limits.MAX_IDENTIFIER_LENGTH)
            return new DummyStatementNode( aggregateName, cm );

I did change the generated code slightly. In particular, I replaced references to jj_consume_token()
with references to consume_token(). And I removed some NOP code which javacc generated.


M       java/engine/org/apache/derby/impl/sql/compile/ParserImpl.java

Changed the Parser to create and call an alternative parser if a statement can't be digested.

> Make it possible to plug alternative parsers into Derby.
> --------------------------------------------------------
>                 Key: DERBY-6385
>                 URL: https://issues.apache.org/jira/browse/DERBY-6385
>             Project: Derby
>          Issue Type: Improvement
>          Components: SQL
>    Affects Versions:
>            Reporter: Rick Hillegas
>         Attachments: plugableParser.diff
> It would be nice to be able to plug alternative parsers into Derby. In particular, it
would be useful to be able to declare a list of parsers which Derby could walk through, looking
for one which could digest a SQL statement. This, in turn, could be useful for optional tools
which need to load/unload optional language into/from the parser. When you load the optional
tool, it could add its parser to the end of the list. When you unload the optional tool, it
could remove its parser from the list.

This message was sent by Atlassian JIRA

View raw message