[ 
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)

Reply via email to