[
https://issues.apache.org/jira/browse/CALCITE-1742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15961102#comment-15961102
]
Maryann Xue commented on CALCITE-1742:
--------------------------------------
bq. Do we know why the TableEntry found in schema could not be unwrapped into a
PreparingTable instance?
The instance returned, whether being an implicit table or an explicit one, can
be anything that implements the {{Table}} interface or its sub-interface, as
specified by the schema SPI. And I believe in most cases, the instance does not
{{PreparingTable}}, so the code hits L149 more often than not. Right now
MockTable is only thing I can find that will go down the "unwrap" path. And the
unwrap logic here is to avoid extra wrapping of "RelOptTableImpl".
> CalciteCatalogReader should not add resolved tables into CalciteSchema's
> explicit table map
> -------------------------------------------------------------------------------------------
>
> Key: CALCITE-1742
> URL: https://issues.apache.org/jira/browse/CALCITE-1742
> Project: Calcite
> Issue Type: Bug
> Components: core
> Affects Versions: 1.12.0
> Reporter: Maryann Xue
> Assignee: Maryann Xue
>
> {{CalciteSchema}} is designed to have two sets of objects, the explicit and
> the implicit. A explicit object means an object we add through explicit
> {{CalciteSchema#addTable}} (or {{CalciteSchema.addFunction}}, etc) calls,
> while an implicit object means an object we get from the underlying
> {{Schema}} object's getXXX methods.
>
> However, in {{CalciteCatalogReader#getTableFrom}}, after a table is resolved
> through {{CalciteSchema.getTable}} method, it will be added to the
> {{CalciteSchema}} again as an explicit object regardless of whether it is
> originally implicit or explicit. So if it happens to be an implicit table,
> any change about that table later on will be shadowed by the newly added
> explicit object and thus cannot be accessed.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
