[jira] [Comment Edited] (PHOENIX-2523) Use same client/server caching mechanism for Phoenix/Calcite

["Julian Hyde (JIRA)" <ji...@apache.org>]

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

Julian Hyde edited comment on PHOENIX-2523 at 12/15/15 5:47 AM:
----------------------------------------------------------------

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

{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.


was (Author: julianhyde):
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)