[ 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)