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 <ayelet.mor...@gigaspaces.com>
> 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]*, 86400000L))
>
> 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 <ayelet.mor...@gigaspaces.com>
>> 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],
>> 86400000L)));
>> }
>>
>> 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
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
