[
https://issues.apache.org/jira/browse/PHOENIX-2199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15182246#comment-15182246
]
Kaide Mu commented on PHOENIX-2199:
-----------------------------------
Thanks for the replay [~jamestaylor], I'll try to get in touch with
[~rajeshbabu] leaving a message in Phonexis-2228, although I'm trying to run
CalciteIT.java of Calcite branch which runs days before (perhaps it was another
vesion(?)), but now it shows me some error message when I try to run such test,
those errors seem are related with PhoenixRel such as:
{noformat}
Error:(27, 42) java: no suitable method found for
reflectiveSource(java.lang.reflect.Method,org.apache.phoenix.calcite.metadata.PhoenixRelMdCollation)
method
org.apache.calcite.rel.metadata.ReflectiveRelMetadataProvider.reflectiveSource(org.apache.calcite.rel.metadata.MetadataHandler,com.google.common.collect.ImmutableList<java.lang.reflect.Method>)
is not applicable
(actual argument java.lang.reflect.Method cannot be converted to
org.apache.calcite.rel.metadata.MetadataHandler by method invocation conversion)
method
org.apache.calcite.rel.metadata.ReflectiveRelMetadataProvider.reflectiveSource(java.lang.reflect.Method,org.apache.calcite.rel.metadata.MetadataHandler)
is not applicable
(actual argument
org.apache.phoenix.calcite.metadata.PhoenixRelMdCollation cannot be converted
to org.apache.calcite.rel.metadata.MetadataHandler by method invocation
conversion)
method
org.apache.calcite.rel.metadata.ReflectiveRelMetadataProvider.reflectiveSource(org.apache.calcite.rel.metadata.MetadataHandler,java.lang.reflect.Method...)
is not applicable
(actual argument java.lang.reflect.Method cannot be converted to
org.apache.calcite.rel.metadata.MetadataHandler by method invocation conversion)
{noformat}
> 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)