[
https://issues.apache.org/jira/browse/CALCITE-4179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17181251#comment-17181251
]
Laurent Goujon commented on CALCITE-4179:
-----------------------------------------
Likely. I went over open JIRAs to find similar issues but didn't see that one,
so thanks for pointing it to me.
One question I have is regarding to backward compatibility because breaking
those dependencies might require changes to public interfaces, and although we
could try to maintain those while using {{@Deprecated}}, it could also make
harder to enforce the policy for future changes.
> org.apache.calcite.jdbc package polluting core Calcite planning packages
> ------------------------------------------------------------------------
>
> Key: CALCITE-4179
> URL: https://issues.apache.org/jira/browse/CALCITE-4179
> Project: Calcite
> Issue Type: Bug
> Components: core
> Reporter: Laurent Goujon
> Priority: Major
>
> Several classes under {{org.apache.calcite.jdbc}} package are used by
> planning classes. As those JDBC classes are some form of implementation, it
> means the Calcite API has some kind of coupling, causing extra challenges for
> alternate implementations.
> One of the central classes of {{org.apache.calcite.jdbc}} is
> {{CalciteSchema}} which represents the catalog space. This class is designed
> to load the entire catalog and hold it in memory, which is a problem for
> those having catalogs too large for this to be practical. This class is
> sometimes used instead of the more generic {{Schema}} and {{SchemaPlus}}
> classes.
> Another similar class is {{CalcitePrepare}}: the class is for example used by
> {{org.apache.calcite.prepare.Prepare}} instead of the dependency being the
> other way around.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
