[jira] [Resolved] (CALCITE-582) EnumerableTableScan broken when table has single column

["Julian Hyde (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CALCITE-582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Julian Hyde resolved CALCITE-582.
---------------------------------
       Resolution: Fixed
    Fix Version/s: 1.0.0-incubating

Fixed in http://git-wip-us.apache.org/repos/asf/incubator-calcite/commit/6c5dd431.

> EnumerableTableScan broken when table has single column
> -------------------------------------------------------
>
>                 Key: CALCITE-582
>                 URL: https://issues.apache.org/jira/browse/CALCITE-582
>             Project: Calcite
>          Issue Type: Bug
>            Reporter: Julian Hyde
>            Assignee: Julian Hyde
>             Fix For: 1.0.0-incubating
>
>
> Vladimir writes:
> {quote}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-488 this 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.{quote}
> And further:
> {quote}Here's additional test case:
> https://github.com/vlsi/incubator-calcite/commit/f8ec9591ee6be3ce670dfeeb7ff076ae0c9f1345
> testModelCustomTableArrayRowSingleColumn 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.{quote}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)