James Taylor created PHOENIX-2199:
-------------------------------------
Summary: Support DDL in Phoenix-Calcite integration
Key: PHOENIX-2199
URL: https://issues.apache.org/jira/browse/PHOENIX-2199
Project: Phoenix
Issue Type: New Feature
Reporter: James Taylor
The existing Phoenix compiler classes are of the form Create<SQL type>Compiler.
For example CreateTableCompiler handles both VIEW and TABLE compilation,
CreateSequenceCompiler is for CREATE SEQEUNCE, and CreateIndexCompiler is for
CREATE INDEX. The compiler class does most of the validation and then calls a
MetaDataClient method to update the meta data repository.
As a general implementation strategy, we'd transfer over the validation code
from the compiler methods to new classes plugged into the JavaCC compilation of
Calcite and then have these new classes call the same, somewhat modified
MetaDataClient APIs. A slightly more detailed breakdown of the work includes:
- Creating new JavaCC rules using the same templating technique as we did for
CREATE VIEW (see https://github.com/apache/phoenix/pull/113/commits), marking
the parse node produced as DDL.
- Producing the information required while the Calcite parser is running to
enable the call to the appropriate MetaDataClient API to update the metadata
repository.
- Tweaking the MetaDataClient APIs to not depend on the objects created at
parse time, but instead pass through the constituent parts. For example,
instead of passing through a CreateTableStatement object in the
MetaDataClient.createTable() call, only the necessary member variables would be
passed through. The idea would be to break the dependency on parse-time object
after compilation is complete.
- Changing ParseNode references used in MetaDataClient, as we don't want to
continue maintaining these. By ParseNode, I mean the parts in the grammar that
match an expression and produce a ParseNode instance. For DDL, this is the
CreateIndexStatement object, which stores a list of ParseNodes as the indexed
expressions. These are currently processed in MetaDataClient, so these could be
changed to either Expressions or RexNodes.
- Collecting at parse time the list of UDFs that need to be resolved. I see
this in CreateIndexStatement, but not CreateTableStatement (which I believe is
an oversight - probably wouldn't work to reference a UDF in the WHERE clause of
a view).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)