calcite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Hyde <jh...@apache.org>
Subject Re: Assertion check in RelOptTableImpl.create()
Date Sat, 09 Jan 2016 01:24:11 GMT
Tables created using “create(RelOptSchema, RelDataType, Table)” have their names field
set to the empty list. That is, they don’t know their location within the schema hierarchy
and in fact may not be in the schema hierarchy. Usually a table implements itself by generating
code like

  rootSchema.getSubSchema(“FOODMART”).getTable(“CUSTOMERS”)

But such “free floating” tables cannot implement themselves in that way. Therefore this
method is only for kinds of tables that know how to get to their own data: TranslatableTable,
ModifiableTable, ScannableTable.

Julian


> On Jan 7, 2016, at 5:40 PM, Jinfeng Ni <jni@apache.org> wrote:
> 
> Does anyone know why one of the static create() methods in
> RelOptTableImpl has the following assertion check (to check table is
> instance of TranslatableTable, or ScannableTable, or ModifiableTable)
> [1], while the rest of create() methods do not do such check? [2]
> 
> Looks like RelOptTableImpl.toRel() actually expects table instance
> other than the above three class[3].
> 
> Does it makes sense to remove the assertion check in [1]?
> 
> Best Regards,
> 
> Jinfeng
> 
> 
> [1]. https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/prepare/RelOptTableImpl.java#L167-L169
> 
> [2] https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/prepare/RelOptTableImpl.java#L118
> 
> [3] https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/prepare/RelOptTableImpl.java#L225


Mime
View raw message