phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kaide Mu (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (PHOENIX-2199) Support DDL in Phoenix-Calcite integration
Date Sun, 06 Mar 2016 17:41:40 GMT

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

Mime
View raw message