[
https://issues.apache.org/jira/browse/CALCITE-1742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15965146#comment-15965146
]
Maryann Xue edited comment on CALCITE-1742 at 4/11/17 11:45 PM:
----------------------------------------------------------------
Thank you, [~jni], for the feedback!
bq. I have one question. Will it cause problem if CsvSchema only initializes
"tableMap" just once? What if the files in one the directory have been added /
deleted between multiple statement execution?
Yes, if we go down solution 1, it may make {{Schema}} implementations more
complicated. They have to make sure to return always the same {{Table}} object
for a specific table name within each Statement, and meanwhile to return a new
{{Table}} object if its content has been updated. So in this sense, I am now
more inclined towards option 2, in which CalciteSchema should maintain a
separate map for tables that have been queried since the start of each
statement and this map should be reset before a new Statement starts.
was (Author: maryannxue):
Thank you, [~jni], for the feedback!
bq. I have one question. Will it cause problem if CsvSchema only initializes
"tableMap" just once? What if the files in one the directory have been added /
deleted between multiple statement execution?
Yes, if we go down solution 1, it may make {{Schema}} implementations more
complicated. They have to make sure to return always the same {{Table}} object
for a specific table name within each Statement, and meanwhile to return a new
{{Table}} object if the its content has been updated. So in this sense, I am
not more inclined towards option 2, in which CalciteSchema should maintain a
separate map for tables that have been queried since the start of each
statement and this map should be reset before a new Statement starts.
> 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)
