[
https://issues.apache.org/jira/browse/CALCITE-1742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15965169#comment-15965169
]
Julian Hyde commented on CALCITE-1742:
--------------------------------------
It's reasonable for the client of the schema SPI (i.e. the preparing statement)
to expect read consistency. During preparation, and also if the statement is
re-executed.
So, then the question is: How burdensome is for the implementor of the schema
SPI to achieve this? Should we introduce a wrapper to ensure that if the same
question is asked twice, we always get the same answer? ({{CalciteSchema}} is
such a wrapper.)
There is an existing mechanism for a {{Schema}} to indicate whether its
contents have changed: [Schema.contentsHaveChangedSince(long,
long)|https://calcite.apache.org/apidocs/org/apache/calcite/schema/Schema.html#contentsHaveChangedSince-long-long-].
Is it adequate?
> 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)
