[
https://issues.apache.org/jira/browse/CALCITE-1748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15977358#comment-15977358
]
Maryann Xue edited comment on CALCITE-1748 at 4/20/17 8:01 PM:
---------------------------------------------------------------
So basically once we have a read consistency layer inside {{CalciteSchema}},
the underlying {{Schema}} implementor can be as simple as query and return the
latest status it can see when "getXXX" methods are called. It is not strictly a
snapshot of a single point in time, but it's close and since we cache all the
answers in this read consistency layer it is strictly consistent. Having an
optional "timestamp" parameter will give the underlying {{Schema}} implementor
a chance to implement a real "snapshot" and even with a custom timestamp
different from the current time.
Otherwise, as an alternative approach, if {{CalciteSchema}} does not take care
of read consistency, the "timestamp" parameter will have to be mandatory, as a
way of indicating the "read consistency point" to the underlying {{Schema}}
instance, and the each {{Schema}} instance has to guarantee consistency.
was (Author: maryannxue):
So basically once we have a read consistency layer inside {{CalciteSchema}},
the underlying {{Schema}} implementor can be as simply as query and return the
latest status it can see when "getXXX" methods are called. It is not strictly a
snapshot of a single point in time, but it's close and since we cache all the
answers in this read consistency layer it is strictly consistent. Having an
optional "timestamp" parameter will give the underlying {{Schema}} implementor
a chance to implement a real "snapshot" and even with a custom timestamp
different from the current time.
Otherwise, as an alternative approach, if {{CalciteSchema}} does not take care
of read consistency, the "timestamp" parameter will have to be mandatory, as a
way of indicating the "read consistency point" to the underlying {{Schema}}
instance, and the each {{Schema}} instance has to guarantee consistency.
> Make CalciteCatalogReader.getSchema extendable to support dynamically load
> schema tree - getSchema need to be set to protected to allow overriding
> --------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: CALCITE-1748
> URL: https://issues.apache.org/jira/browse/CALCITE-1748
> Project: Calcite
> Issue Type: Bug
> Reporter: Chunhui Shi
> Assignee: Julian Hyde
>
> In system like Drill, there is a need to load partial schema (e.g. for only
> one storage plugin) only when needed. Since Drill has no way to get a full
> available schema tree before hand, nor could Drill cache available schema for
> a storage plugin(e.g. Hive, MongoDB) since the storage plugin may not have
> notification mechanism to update Schema tree timely.
>
> The proposed fix is to load schema dynamically as shown in
> https://issues.apache.org/jira/browse/DRILL-5089
> To achieve this, we need to make CalciteCatalogReader.getSchema to be
> protected so it could be overridden by derived class while the derived class
> can reuse other functionalities in CalciteCatalogReader class
> private CalciteSchema getSchema(Iterable<String> schemaNames,
> SqlNameMatcher nameMatcher)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
