I do think it is a bug in Avatica since I was able to reproduce the issue with the CsvTest. I logged it as CALCITE-898 with details about how to reproduce the problem.
Jan On Thu, Sep 24, 2015 at 9:12 PM, Julian Hyde <[email protected]> wrote: > It is a bug in one of two places. It might be a bug in Avatica; or > might be a bug in the underlying server, that is claiming to return > the result using int as the physical type (hence the IntAccessor) but > is actually returning longs. It's hard to say which of those places, > but your SQL is not at fault. > > On Thu, Sep 24, 2015 at 5:16 AM, Jan Van Besien <[email protected]> wrote: >> I am in the process of upgrading a JDBC driver implementation with >> calcite from 0.9.2 to 1.4.0. On a table with an ID field that is >> defined as java.sql.Types.BIGINT, I used to be able to write queries >> like these in calcite 0.9.2 (at least). >> >> select id * 3 from table >> >> Now (1.4.0) I have to write >> >> select id * cast(3 as bigint) from table >> >> If not, I get a ClassCastException >> >> java.lang.ClassCastException: java.lang.Long cannot be cast to >> java.lang.Integer >> at >> org.apache.calcite.avatica.util.AbstractCursor$IntAccessor.getInt(AbstractCursor.java:485) >> at org.apache.calcite.avatica.AvaticaSite.get(AvaticaSite.java:338) >> at >> org.apache.calcite.avatica.AvaticaResultSet.getObject(AvaticaResultSet.java:381) >> ... >> >> Is there a good reason for this change or is it a bug? >> >> Thanks >> Jan
