[
https://issues.apache.org/jira/browse/CALCITE-1742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15965211#comment-15965211
]
Maryann Xue commented on CALCITE-1742:
--------------------------------------
bq. 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.)
The question is: Can the implementor of schema SPI know the boundary between
different Statements? If the question is asked twice within the same Statement,
the answer should always be the same. And when it comes to the next Statement,
it should be able to answer what it is like as of the new Statement time. So in
order to allow the implementor to do that, we can either 1) provide a reset
callback/mechanism in schema SPI or 2) provide an extra parameter "timestamp"
or "query id" each time we call {{getTable}} from the schema implementor.
Either way it would make the SPI unnecessarily more complicated I think. Doing
this in the wrapper, i.e., CalciteSchema is certainly much simpler.
Right now Phoenix/Calcite integration maintains a map in {{PhoenixSchema}}
(originally not for this purpose), but has to take advantage of the Hooks to
clear the map right before a Statement starts, which is definitely not
preferred.
bq. There is an existing mechanism for a Schema to indicate whether its
contents have changed: Schema.contentsHaveChangedSince(long, long). Is it
adequate?
According to javadoc, the {{Schema.contentsHaveChangedSince(long, long)}}
method is designed for schema caching and the thing we are talking about right
now is a different issue and it should work regardless of whether caching is
enabled. And even if the application of this method could be extended for this
more general purpose, we still need some other mechanism to help it work, and
we will be back at the above question again. For example, if
"contentsHaveChanged" returns true for our next Statement, we'll have to call a
method like "update" on the schema implementor, and this sounds like a combined
approach of 1) and 2) mentioned above, coz we have both "reset/update" method
and a "timestamp" (from {{contentsHaveChanged}}).
> 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)
