Re: Advise on ClassCastException in Linq4j$EnumeratorIterator

2020-05-05 Thread Julian Hyde
To repeat. In Enumerable convention, a SQL TIMESTAMP value must be represented 
as a Java Long value. 

Julian

PS Please subscribe to the dev list, to avoid moderation delays. And do not 
email issues@; it is only for automatically generated emails.

> On May 5, 2020, at 7:22 AM, Ayelet Morris  
> wrote:
> 
> Sorry about the last email, it was a bit early...
> I found the exact location of the exception, in the current() method you
> can see the wrong cast:
> DateTimeUtils.floorDiv(*(Long) current[8]*, 8640L))
> 
> As I explained earlier, the type of the field is TIMESTAMP, and it cannot
> be cast to long this way...
> 
> please advise
> 
>> On Tue, May 5, 2020 at 7:27 AM Ayelet Morris 
>> wrote:
>> 
>> + Calcite support mailing list.
>> 
>> Hi again,
>> 
>> I didn't receive any response from you guys, but I continued to debug this
>> today and managed to print the generated code and I saw a weird casting
>> that might explain what happens there:
>> public Object current() {
>>  final Object[] current = (Object[])
>> inputEnumerator.current();
>>  return* (java.sql.Timestamp) *current[8] == null ?* (Long)*
>> null : 
>> *Long.valueOf*(org.apache.calcite.avatica.util.DateTimeUtils.unixDateExtract(org.apache.calcite.avatica.util.TimeUnitRange.DAY,
>> org.apache.calcite.avatica.util.DateTimeUtils.floorDiv((Long) current[8],
>> 8640L)));
>> }
>> 
>> public Class getElementType() {
>>   return *java.lang.Long.class*;
>> }
>> 
>> 
>> I marked in *bold* the interesting casting that happens there that I need
>> your help understanding:
>> it seems that the code casts the value into long and then re-casts it to
>> timestamp only to return as long, as you can see the element type is marked
>> as long...
>> Do you know why the generated code was generated this way? the field is
>> TIMESTAMP and the return value from the SQL function should be long...
>> 
>> Hope you are all well.
>> Thanks!
>> Ayelet
>> 
>> On Mon, Apr 27, 2020 at 4:49 PM Ayelet Morris <
>> ayelet.mor...@gigaspaces.com> wrote:
>> 
>>> Hi Calcite Developers,
>>> Hope you are all doing well at this crazy time.
>>> 
>>> I have a question regarding Linq4j$EnumeratorIterator
>>> throwing ClassCastException.
>>> *Background*: I'm running a Tableau testing framework called TDVT (it's
>>> in beta) in order to test our product's JDBC connector.  Our product uses
>>> Calcite 1.21.0 and Avatics 1.15.0.
>>> 
>>> I encountered this class cast exception when running timestamp related
>>> sql functions (I have about 127 different SQLs failing with the same class
>>> cast exception).
>>> *My SQL**:* select DAYOFMONTH(datetime0) from Calcs
>>> datetime0 is a java.sql.Timestamp field in my POJO, the data in the CSV
>>> I'm using to fill in the POJO is written like this: '2004-07-23 21:13:37'
>>> *The exception:*
>>> ClassCastException: java.sql.Timestamp cannot be cast to java.lang.Long
>>> at Baz$1$1.current(Unknown Source)
>>> at
>>> org.apache.calcite.linq4j.Linq4j$EnumeratorIterator.next(Linq4j.java:683)
>>> at
>>> org.apache.calcite.avatica.util.IteratorCursor.next(IteratorCursor.java:46)
>>> at
>>> org.apache.calcite.avatica.AvaticaResultSet.next(AvaticaResultSet.java:217)
>>> at com.gigaspaces.jdbc.TimestampTest.test(TimestampTest.java:64)
>>> 
>>> This exception is thrown when trying to perform "next()"
>>> I cannot debug the generated code... I just see it being thrown there.
>>> 
>>> I looked into the generated code for performing this (and similar) sql
>>> function and couldn't find a specific time format that is required, but in
>>> the documentation I saw the use of java.sql.Date as the function type, I
>>> tried to run my test with Date field I have in my POJO and it did return a
>>> correct result.
>>> I suspect it might not be compatible with Timestamp data type, though I
>>> saw in your tests you do test with timestamp '2008-1-23 12:12:12', I
>>> didn't try to run the test in the DruidAdapter suite but I saw that you are
>>> using a timestamp based column there.
>>> 
>>> Do you know of a reason for this exception at this location? Did you see
>>> this exception before at this location? Do you have any idea where I should
>>> look for further information/clues?
>>> 
>>> Thanks,
>>> Ayelet
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 


Re: Advise on ClassCastException in Linq4j$EnumeratorIterator

2020-05-05 Thread Ayelet Morris
+ Calcite support mailing list.

Hi again,

I didn't receive any response from you guys, but I continued to debug this
today and managed to print the generated code and I saw a weird casting
that might explain what happens there:
 public Object current() {
  final Object[] current = (Object[]) inputEnumerator.current();
  return* (java.sql.Timestamp) *current[8] == null ?* (Long)*
null : 
*Long.valueOf*(org.apache.calcite.avatica.util.DateTimeUtils.unixDateExtract(org.apache.calcite.avatica.util.TimeUnitRange.DAY,
org.apache.calcite.avatica.util.DateTimeUtils.floorDiv((Long) current[8],
8640L)));
 }

public Class getElementType() {
   return *java.lang.Long.class*;
 }


I marked in *bold* the interesting casting that happens there that I need
your help understanding:
it seems that the code casts the value into long and then re-casts it to
timestamp only to return as long, as you can see the element type is marked
as long...
Do you know why the generated code was generated this way? the field is
TIMESTAMP and the return value from the SQL function should be long...

Hope you are all well.
Thanks!
Ayelet

On Mon, Apr 27, 2020 at 4:49 PM Ayelet Morris 
wrote:

> Hi Calcite Developers,
> Hope you are all doing well at this crazy time.
>
> I have a question regarding Linq4j$EnumeratorIterator
> throwing ClassCastException.
> *Background*: I'm running a Tableau testing framework called TDVT (it's
> in beta) in order to test our product's JDBC connector.  Our product uses
> Calcite 1.21.0 and Avatics 1.15.0.
>
> I encountered this class cast exception when running timestamp related sql
> functions (I have about 127 different SQLs failing with the same class cast
> exception).
> *My SQL**:* select DAYOFMONTH(datetime0) from Calcs
> datetime0 is a java.sql.Timestamp field in my POJO, the data in the CSV
> I'm using to fill in the POJO is written like this: '2004-07-23 21:13:37'
> *The exception:*
> ClassCastException: java.sql.Timestamp cannot be cast to java.lang.Long
> at Baz$1$1.current(Unknown Source)
> at
> org.apache.calcite.linq4j.Linq4j$EnumeratorIterator.next(Linq4j.java:683)
> at
> org.apache.calcite.avatica.util.IteratorCursor.next(IteratorCursor.java:46)
> at
> org.apache.calcite.avatica.AvaticaResultSet.next(AvaticaResultSet.java:217)
> at com.gigaspaces.jdbc.TimestampTest.test(TimestampTest.java:64)
>
> This exception is thrown when trying to perform "next()"
> I cannot debug the generated code... I just see it being thrown there.
>
> I looked into the generated code for performing this (and similar) sql
> function and couldn't find a specific time format that is required, but in
> the documentation I saw the use of java.sql.Date as the function type, I
> tried to run my test with Date field I have in my POJO and it did return a
> correct result.
> I suspect it might not be compatible with Timestamp data type, though I
> saw in your tests you do test with timestamp '2008-1-23 12:12:12', I
> didn't try to run the test in the DruidAdapter suite but I saw that you are
> using a timestamp based column there.
>
> Do you know of a reason for this exception at this location? Did you see
> this exception before at this location? Do you have any idea where I should
> look for further information/clues?
>
> Thanks,
> Ayelet
>
>
>
>
>
>
>
>
>


Re: Advise on ClassCastException in Linq4j$EnumeratorIterator

2020-05-05 Thread Ayelet Morris
Sorry about the last email, it was a bit early...
I found the exact location of the exception, in the current() method you
can see the wrong cast:
DateTimeUtils.floorDiv(*(Long) current[8]*, 8640L))

As I explained earlier, the type of the field is TIMESTAMP, and it cannot
be cast to long this way...

please advise

On Tue, May 5, 2020 at 7:27 AM Ayelet Morris 
wrote:

> + Calcite support mailing list.
>
> Hi again,
>
> I didn't receive any response from you guys, but I continued to debug this
> today and managed to print the generated code and I saw a weird casting
> that might explain what happens there:
>  public Object current() {
>   final Object[] current = (Object[])
> inputEnumerator.current();
>   return* (java.sql.Timestamp) *current[8] == null ?* (Long)*
> null : 
> *Long.valueOf*(org.apache.calcite.avatica.util.DateTimeUtils.unixDateExtract(org.apache.calcite.avatica.util.TimeUnitRange.DAY,
> org.apache.calcite.avatica.util.DateTimeUtils.floorDiv((Long) current[8],
> 8640L)));
>  }
>
> public Class getElementType() {
>return *java.lang.Long.class*;
>  }
>
>
> I marked in *bold* the interesting casting that happens there that I need
> your help understanding:
> it seems that the code casts the value into long and then re-casts it to
> timestamp only to return as long, as you can see the element type is marked
> as long...
> Do you know why the generated code was generated this way? the field is
> TIMESTAMP and the return value from the SQL function should be long...
>
> Hope you are all well.
> Thanks!
> Ayelet
>
> On Mon, Apr 27, 2020 at 4:49 PM Ayelet Morris <
> ayelet.mor...@gigaspaces.com> wrote:
>
>> Hi Calcite Developers,
>> Hope you are all doing well at this crazy time.
>>
>> I have a question regarding Linq4j$EnumeratorIterator
>> throwing ClassCastException.
>> *Background*: I'm running a Tableau testing framework called TDVT (it's
>> in beta) in order to test our product's JDBC connector.  Our product uses
>> Calcite 1.21.0 and Avatics 1.15.0.
>>
>> I encountered this class cast exception when running timestamp related
>> sql functions (I have about 127 different SQLs failing with the same class
>> cast exception).
>> *My SQL**:* select DAYOFMONTH(datetime0) from Calcs
>> datetime0 is a java.sql.Timestamp field in my POJO, the data in the CSV
>> I'm using to fill in the POJO is written like this: '2004-07-23 21:13:37'
>> *The exception:*
>> ClassCastException: java.sql.Timestamp cannot be cast to java.lang.Long
>> at Baz$1$1.current(Unknown Source)
>> at
>> org.apache.calcite.linq4j.Linq4j$EnumeratorIterator.next(Linq4j.java:683)
>> at
>> org.apache.calcite.avatica.util.IteratorCursor.next(IteratorCursor.java:46)
>> at
>> org.apache.calcite.avatica.AvaticaResultSet.next(AvaticaResultSet.java:217)
>> at com.gigaspaces.jdbc.TimestampTest.test(TimestampTest.java:64)
>>
>> This exception is thrown when trying to perform "next()"
>> I cannot debug the generated code... I just see it being thrown there.
>>
>> I looked into the generated code for performing this (and similar) sql
>> function and couldn't find a specific time format that is required, but in
>> the documentation I saw the use of java.sql.Date as the function type, I
>> tried to run my test with Date field I have in my POJO and it did return a
>> correct result.
>> I suspect it might not be compatible with Timestamp data type, though I
>> saw in your tests you do test with timestamp '2008-1-23 12:12:12', I
>> didn't try to run the test in the DruidAdapter suite but I saw that you are
>> using a timestamp based column there.
>>
>> Do you know of a reason for this exception at this location? Did you see
>> this exception before at this location? Do you have any idea where I should
>> look for further information/clues?
>>
>> Thanks,
>> Ayelet
>>
>>
>>
>>
>>
>>
>>
>>
>>


Re: Advise on ClassCastException in Linq4j$EnumeratorIterator

2020-04-27 Thread Julian Hyde
In the Enumerable convention, values of SQL datatype TIMESTAMP are represented 
using Java values of type java.lang.Long.

Not sure exactly what you’re doing wrong, but your query (or other code) that 
gets the values into Java should be getting them as Long, not as 
java.sql.Timestamp values. This issue has occurred before, and a search of JIRA 
or the dev@ archive might yield results.

Julian




> On Apr 27, 2020, at 6:49 AM, Ayelet Morris  
> wrote:
> 
> Hi Calcite Developers,
> Hope you are all doing well at this crazy time.
> 
> I have a question regarding Linq4j$EnumeratorIterator
> throwing ClassCastException.
> *Background*: I'm running a Tableau testing framework called TDVT (it's in
> beta) in order to test our product's JDBC connector.  Our product uses
> Calcite 1.21.0 and Avatics 1.15.0.
> 
> I encountered this class cast exception when running timestamp related sql
> functions (I have about 127 different SQLs failing with the same class cast
> exception).
> *My SQL**:* select DAYOFMONTH(datetime0) from Calcs
> datetime0 is a java.sql.Timestamp field in my POJO, the data in the CSV I'm
> using to fill in the POJO is written like this: '2004-07-23 21:13:37'
> *The exception:*
> ClassCastException: java.sql.Timestamp cannot be cast to java.lang.Long
> at Baz$1$1.current(Unknown Source)
> at org.apache.calcite.linq4j.Linq4j$EnumeratorIterator.next(Linq4j.java:683)
> at
> org.apache.calcite.avatica.util.IteratorCursor.next(IteratorCursor.java:46)
> at
> org.apache.calcite.avatica.AvaticaResultSet.next(AvaticaResultSet.java:217)
> at com.gigaspaces.jdbc.TimestampTest.test(TimestampTest.java:64)
> 
> This exception is thrown when trying to perform "next()"
> I cannot debug the generated code... I just see it being thrown there.
> 
> I looked into the generated code for performing this (and similar) sql
> function and couldn't find a specific time format that is required, but in
> the documentation I saw the use of java.sql.Date as the function type, I
> tried to run my test with Date field I have in my POJO and it did return a
> correct result.
> I suspect it might not be compatible with Timestamp data type, though I saw
> in your tests you do test with timestamp '2008-1-23 12:12:12', I didn't try
> to run the test in the DruidAdapter suite but I saw that you are using a
> timestamp based column there.
> 
> Do you know of a reason for this exception at this location? Did you see
> this exception before at this location? Do you have any idea where I should
> look for further information/clues?
> 
> Thanks,
> Ayelet



Advise on ClassCastException in Linq4j$EnumeratorIterator

2020-04-27 Thread Ayelet Morris
Hi Calcite Developers,
Hope you are all doing well at this crazy time.

I have a question regarding Linq4j$EnumeratorIterator
throwing ClassCastException.
*Background*: I'm running a Tableau testing framework called TDVT (it's in
beta) in order to test our product's JDBC connector.  Our product uses
Calcite 1.21.0 and Avatics 1.15.0.

I encountered this class cast exception when running timestamp related sql
functions (I have about 127 different SQLs failing with the same class cast
exception).
*My SQL**:* select DAYOFMONTH(datetime0) from Calcs
datetime0 is a java.sql.Timestamp field in my POJO, the data in the CSV I'm
using to fill in the POJO is written like this: '2004-07-23 21:13:37'
*The exception:*
ClassCastException: java.sql.Timestamp cannot be cast to java.lang.Long
at Baz$1$1.current(Unknown Source)
at org.apache.calcite.linq4j.Linq4j$EnumeratorIterator.next(Linq4j.java:683)
at
org.apache.calcite.avatica.util.IteratorCursor.next(IteratorCursor.java:46)
at
org.apache.calcite.avatica.AvaticaResultSet.next(AvaticaResultSet.java:217)
at com.gigaspaces.jdbc.TimestampTest.test(TimestampTest.java:64)

This exception is thrown when trying to perform "next()"
I cannot debug the generated code... I just see it being thrown there.

I looked into the generated code for performing this (and similar) sql
function and couldn't find a specific time format that is required, but in
the documentation I saw the use of java.sql.Date as the function type, I
tried to run my test with Date field I have in my POJO and it did return a
correct result.
I suspect it might not be compatible with Timestamp data type, though I saw
in your tests you do test with timestamp '2008-1-23 12:12:12', I didn't try
to run the test in the DruidAdapter suite but I saw that you are using a
timestamp based column there.

Do you know of a reason for this exception at this location? Did you see
this exception before at this location? Do you have any idea where I should
look for further information/clues?

Thanks,
Ayelet