MockCatalogReader was created for testing, but we don’t intend people to use it (or a modified version of it) in projects that use Calcite.
CalciteSchema is a private class (the Java class is marked “public” only because it is used across several packages) and we don’t intend people to use it. Our intended extension point is Schema. Write your own instance of that API to go and get table definitions on demand. You need to write a getTableNames() method that returns all table names as a set, but you can create the table definitions one at a time when getTable(String name) is called. In https://issues.apache.org/jira/browse/CALCITE-1742 <https://issues.apache.org/jira/browse/CALCITE-1742> we are discussing possibly changing this model, but hopefully in a compatible way. Julian > On Apr 21, 2017, at 8:19 PM, LogSplitter <[email protected]> wrote: > > Hi, > > I am just in the process of updating to the latest version of calcite for my > project and have run into an issue and not sure whether I am missing > something. > > I currently use a process based on some of the code around MockCatalogReader > to create a catalog and allow my sql to get parsed to relational algebra, > which is all I use from the calcite side of things. > > I was able to dynamically look up metadata previously in the code by having > the CatalogReader getTable code lazily load the metadata items as it received > request for tables. > > It seems with the 1.12 code and the requirement to use calciteSchema it > expects all the schemas and tables to be available all the time. > > I am wondering if my lazy load approach is a mistake or if I should work on > the calciteSchema interface to allow it to continue with this behaviour. > > Does anyone have thoughts on if what I am trying to do makes sense. > > thanks > >
