Schema (and SchemaPlus) is a namespace used to look up object names when 
validating a SQL query. It is not strictly required if you are building the 
query manually, or using RelBuilder. The key is the TableScan objects (in this 
case JdbcTableScan) representing accesses to tables.

Those tables could be foreign tables in the same schema, or in different 
schemas, or be free-floating objects not in any schema at all. The important 
thing is the instance of JdbcConvention in their TableScan.getTraitSet(). That 
JdbcConvention contains the URL of the database, its dialect, etc. With 
different JdbcConvention instances you could join a table in an Oracle database 
to a table in a table in a SqlServer database or even in a different Oracle 

But if two tables are in the same Oracle database they must have the same 
JdbcConvention instance. Otherwise Calcite will not consider creating a 
JdbcJoin (i.e. a join inside the target database).


> On Feb 13, 2018, at 10:01 PM, Abbas Gadhia <> 
> wrote:
> Hi,
> I want to build a RelNode tree with different conventions on different 
> RelNodes (for example: in the following select query "select * from t1,t2", 
> t1 is a table from Oracle and t2 is a table from SqlServer). 
> I'm confused whether i should be using a single SchemaPlus to hold table 
> references from both Oracle and SqlServer or I should be creating a different 
> SchemaPlus for each product. Different SchemaPlus would force me to use a 
> different RelBuilder, so my guess is that a single SchemaPlus with the 
> following hierarchy may suffice ("oracle" -> "database1" -> "schema1" -> 
> "t1"). However, I suspect this single hierarchy (with the product name 
> inside) may not play well with other parts of Calcite.
> Any thoughts, however small would be appreciated.
> Thanks
> Abbas

Reply via email to