calcite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Hyde <>
Subject Re: Question about CalciteSchema in 1.12
Date Sat, 22 Apr 2017 04:32:07 GMT
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 <>
we are discussing possibly changing this model, but hopefully in a compatible way.


> On Apr 21, 2017, at 8:19 PM, LogSplitter <> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message