explicit cast required where not expected

[Jan Van Besien <ja...@ngdata.com>]

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

Re: explicit cast required where not expected

[Jan Van Besien <ja...@ngdata.com>]

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 <jh...@apache.org> 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 <ja...@ngdata.com> 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

Re: explicit cast required where not expected

[Julian Hyde <jh...@apache.org>]

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 <ja...@ngdata.com> 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