[
https://issues.apache.org/jira/browse/PHOENIX-2199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15171251#comment-15171251
]
Kaide Mu edited comment on PHOENIX-2199 at 2/29/16 12:25 AM:
-------------------------------------------------------------
Hello, dear James Taylor and Apache Phoenix community,
I'm Kaide Mu, currently pursuing BSc of Computer Science at Polytechnic
University of Valencia, Spain.
I'm very interested in work with this issue as my project of GSoC 2016, I'm
comfortable with Java and familiar with SQL.
After briefly reading the issue description and code example provided with
GitHub commit, regarding with "Creating new JavaCC ..." I guess our starting
point is create various Sqlcalls classes for TABLE, VIEW, INDEX, and SEQUENCES
which create parse nodes recognized as DDL statements containing all
corresponding information.
Those parts related with MetaDataClient, I had been looking through its source
code, I guess we aim to adapt existing APIs to DDL classes and substitute
ParseNode object to equivalent RexNode or Expression, but I'm not very clear
with those ideas.
Hence, could you provide me some additional guideline or references that I
should take a look, I'd very appreciate it. Also, please correct me if my
understanding is wrong, thank you so much.
Best regards,
Kaide Mu
> 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
> Labels: calcite, gsoc2016
>
> 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)
