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 <ab_gad...@yahoo.com.INVALID>
> 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.