[
https://issues.apache.org/jira/browse/PHOENIX-3341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15536876#comment-15536876
]
Maryann Xue commented on PHOENIX-3341:
--------------------------------------
[~julianhyde], what's your take on this? CatalogReader calls
"CalciteSchema.add(String, Table)" every time a table has been resolved. Shall
we provide something like a clear() method for CalciteSchema and Phoenix is
going to call it at the start of every statement? We could do some fix work for
the "data update not visible" issue, but it would still be a problem for
dropping or modifying table, functions, etc.
> Data update is not visible to following statements of the same connection due
> to CalciteSchema caching.
> -------------------------------------------------------------------------------------------------------
>
> Key: PHOENIX-3341
> URL: https://issues.apache.org/jira/browse/PHOENIX-3341
> Project: Phoenix
> Issue Type: Sub-task
> Reporter: Maryann Xue
> Assignee: Maryann Xue
> Labels: calcite
>
> The TableRef object contains a timestamp which will be used for TableScan.
> The timestamp should be set at the time of the statement being compiled. Now
> that the table resolving goes from Calcite and CalciteSchema caches
> TableEntry through the whole connection, the table will not be re-resolved if
> any previous statement has already resolved it. If a previous statement did
> an update, the next statement cannot see the update since it's holding a
> TableRef object containing the old timestamp.
> The CalciteSchema caching would also be a problem if a table, a view, or a
> function is modified or dropped.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
