Affects Version/s: None
Fix Version/s: 1.0.0-incubating
The release brings regression in terms of
AbstractQueryableTable(Object) vs EnumerableTableScan interaction.
I am not sure what is the best way to solve it.
I suspect EnumerableTableScan users are impacted.
Historically, Calcite treated AbstractQueryableTable(Object.class)
in a tricky way:
1) If the row type has more than one column, then Calcite expects
2) If the row type has just a single column, then Calcite expects
CALCITE-488this behavior was broken so for Object.class tables
Calcite always expects Object boxed rows.
From one view this new behavior is "less surprising", however the
change was not intended.
For instance, smart-csv-example is broken since it tries to use
adaptive enumerator type depending on the number of projected columns.
In particular, the change impacts my mat-calcite-plugin and I have no
idea how I missed that when I was testing previous RC.
I would suggest revert to the old mode when Object.class kind of
tables skip Object array for single-column rows.
Well, the PhysType vs elementType API should be improved, however I
would not want that improvement to hold the train.
Here's additional test case:
testModelCustomTableArrayRowSingleColumn breaks with
java.lang.ClassCastException: java.lang.Integer cannot be cast to
A naive fix (https://github.com/vlsi/incubator-calcite/commit/20d274c0526499cf06e0e61c6d49faf5a8ae7296)
breaks ScannableTable: it looks like scan always returns Object,
however EnumerableTableScan requires scalars for single columns.