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 database. 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). Julian > On Feb 13, 2018, at 10:01 PM, Abbas Gadhia <[email protected]> > 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 >
