[ 
https://issues.apache.org/jira/browse/PHOENIX-2523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15057385#comment-15057385
 ] 

Julian Hyde commented on PHOENIX-2523:
--------------------------------------

I can't see the big picture just, so I would start by refactoring the existing 
code. The existing materializations come from the loop

{code}
      final List<Prepare.Materialization> materializations =
          config.materializationsEnabled()
              ? MaterializationService.instance().query(rootSchema)
              : ImmutableList.<Prepare.Materialization>of();
      for (Prepare.Materialization materialization : materializations) {
        populateMaterializations(context, planner, materialization);
      }
      final List<CalciteSchema.LatticeEntry> lattices =
          Schemas.getLatticeEntries(rootSchema);
      preparedResult = preparingStmt.prepareSql(
          sqlNode, Object.class, validator, true, materializations, lattices);
{code}

so why not create a callback interface that the planner can call to execute the 
same code when it is ready to find the materializations. When you have that 
working you can evolve the interface into something that belongs on the schema.

> Use same client/server caching mechanism for Phoenix/Calcite
> ------------------------------------------------------------
>
>                 Key: PHOENIX-2523
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-2523
>             Project: Phoenix
>          Issue Type: Bug
>            Reporter: James Taylor
>            Assignee: Maryann Xue
>
> Rather than query through the DatabaseMetaData APIs, Phoenix/Calcite should 
> use the same client/server caching mechanism as standalone Phoenix. One 
> challenge is that Calcite looks at the schema first and then at the tables 
> under that schema (one level at a time), while Phoenix doesn't have a 
> physical representation of a schema. Instead, it resolves a table given the 
> schema name and table name together. One solution may be to never give an 
> error in Phoenix/Calcite when a schema level is traversed, but only actually 
> resolve when the next level is traversed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to