[
https://issues.apache.org/jira/browse/PHOENIX-2199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Taylor updated PHOENIX-2199:
----------------------------------
Assignee: Rajeshbabu Chintaguntla
> Support DDL in Phoenix-Calcite integration
> ------------------------------------------
>
> Key: PHOENIX-2199
> URL: https://issues.apache.org/jira/browse/PHOENIX-2199
> Project: Phoenix
> Issue Type: Task
> Reporter: James Taylor
> Assignee: Rajeshbabu Chintaguntla
> Labels: calcite
>
> 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)
