calcite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jinfeng Ni <jinfengn...@gmail.com>
Subject Re: Assertion check in RelOptTableImpl.create()
Date Mon, 11 Jan 2016 03:37:58 GMT
Sounds good. Thanks!


On Sun, Jan 10, 2016 at 5:58 PM, Julian Hyde <jhyde@apache.org> wrote:
> I don’t think it would do any harm if DrillTable implements ScannableTable. The method
could throw UnsupportedOperationException if you don’t intend to use it.
>
>> On Jan 8, 2016, at 9:58 PM, Jinfeng Ni <jinfengni99@gmail.com> wrote:
>>
>> Thanks for the explanation, Julian.
>>
>> The places where I want to create an instance of RelOptTable is not in
>> SqlValidator or SqlToRelConverter. Rather, it's in a RelOptRule, where
>> CalciteSchema or Path is not available, which makes it not possible to
>> call the other create() methods. In that sense, such table is "free
>> floating" table.
>>
>> The RelOptRule, which essentially is trying to pushing partition
>> filter into scan, has to create a new instance of RelOptTable, after
>> certain transformation. In that sense, it's quite similar to
>> DeltaTableScanRule in Calcite code base [1].  The difference is
>> DeltaTableScanRule has a ScannableTable, while in Drill, DrillTable
>> does not implement ScannableTable [2].
>>
>> Do you think it makes sense to make DrillTable implement ScannableTable?
>>
>> Thanks!
>>
>> [1] https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/rel/stream/StreamRules.java#L192-L195
>> [2] https://github.com/apache/drill/blob/master/exec/java-exec/src/main/java/org/apache/drill/exec/planner/logical/DrillTable.java#L34
>>
>> On Fri, Jan 8, 2016 at 5:24 PM, Julian Hyde <jhyde@apache.org> wrote:
>>> 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