[
https://issues.apache.org/jira/browse/CALCITE-1742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15963875#comment-15963875
]
Maryann Xue commented on CALCITE-1742:
--------------------------------------
[~jni] and [~julianhyde], could you please take a look at
https://github.com/apache/calcite/pull/421?
After removing the two occurrences of {{Schema.addTable}} that I thought were
unnecessary and had side effects, I got two failures from the existing calcite
tests. That was because there were two places which required that for each
table, the same {{Table}} object should be returned within the execution of a
Statement:
1) {{RelOptTableImpl}} compares its underlying {{Table}} object for hash code
generation and equality test.
2) {{CsvTranslatableTable}} will use the {{fieldTypes}} initiated during
compile time.
So I guess {{CalciteCatalogReader}} and {{EmptyScope}} called
{{Schema.addTable}} deliberately for this exact reason. As it is good enough
for a single Statement execution, it does not take into account the fact that
table definitions can change between different Statement executions.
I figured there can be at least two solutions:
1. Require implementations of {{Schema}} SPI always return the same {{Table}}
object for the same table. This is what I did in the PR. I changed
{{ReflectiveSchema}} and {{CsvSchema}} to let them initiate the "tableMap" just
once and return this same tableMap each time.
2. Keep the {{Schema.addSchema}} calls, but clear the "tableMap" between each
Statement. This will make sure that {{Table}} objects do not change within the
same Statement but can change over different Statements.
Any thoughts?
> 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)
