Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Fixed
-
None
-
None
-
None
Description
Vladimir writes:
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
Enumerator<Object[]>
2) If the row type has just a single column, then Calcite expects
"unboxed Object[]".In
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.
And further:
Here's additional test case:
https://github.com/vlsi/incubator-calcite/commit/f8ec9591ee6be3ce670dfeeb7ff076ae0c9f1345testModelCustomTableArrayRowSingleColumn breaks with
java.lang.ClassCastException: java.lang.Integer cannot be cast to
[Ljava.lang.Object;
at Baz$1.apply(ANONYMOUS.java:11)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.