[
https://issues.apache.org/jira/browse/CALCITE-2243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16430590#comment-16430590
]
Markku Vuorenmaa commented on CALCITE-2243:
-------------------------------------------
Well, the example code is calling currentTimeMillis() only once and uses that
return value for all the rows. 'Formatted' column is based on that single
timestamp, the being same for all 200 rows. I think the can be produced with a
constant timestamp if need be.
The original data used when the issue was found was more complicated. Actually,
it was possible to query the same row with different conditions and get two
different timestamps for the same data, depending whether the result is found
before or after the first 100 rows.
In the remote case it's OK to have 3 hour difference according to timezone:
#100 TIME=2018-04-09 11:20:38.31; FORMATTED=9.4.2018 14:20:38
But while it takes couple of seconds to run through the example, the next row
has 6 hour difference:
#101 TIME=2018-04-09 08:20:38.31; FORMATTED=9.4.2018 14:20:38
And the FORMATTED column, based on that single long value does not change.
> Timestamp values change with remote connection when the result set size
> exceeds 100 rows
> ----------------------------------------------------------------------------------------
>
> Key: CALCITE-2243
> URL: https://issues.apache.org/jira/browse/CALCITE-2243
> Project: Calcite
> Issue Type: Bug
> Components: core
> Affects Versions: 1.16.0
> Reporter: Markku Vuorenmaa
> Assignee: Julian Hyde
> Priority: Major
> Attachments: TimestampsIssue.java
>
>
> Table queries with TIMESTAMP values return incorrect values when the result
> set size is larger than 100 rows. Perhaps the timezone shift is calculated
> twice, as the first 100 lines are correct and the bug always occurs after
> that. The default fetch size in the code seems to be 100. The bug should be
> reproducable by running the attached code, which the same model with local
> and remote connection and gets a different data as a result.
> Some output shortly:
> Local:
> {{#1 TIME=2018-04-09 11:20:38.31; FORMATTED=9.4.2018 14:20:38}}
> {{#2 TIME=2018-04-09 11:20:38.31; FORMATTED=9.4.2018 14:20:38}}
> {{#100 TIME=2018-04-09 11:20:38.31; FORMATTED=9.4.2018 14:20:38}}
> {{#101 TIME=2018-04-09 11:20:38.31; FORMATTED=9.4.2018 14:20:38}}
> {{#102 TIME=2018-04-09 11:20:38.31; FORMATTED=9.4.2018 14:20:38}}
> {{#200 TIME=2018-04-09 11:20:38.31; FORMATTED=9.4.2018 14:20:38}}
> Remote:
> {{#1 TIME=2018-04-09 11:20:38.31; FORMATTED=9.4.2018 14:20:38}}
> {{#2 TIME=2018-04-09 11:20:38.31; FORMATTED=9.4.2018 14:20:38}}
> {{#100 TIME=2018-04-09 11:20:38.31; FORMATTED=9.4.2018 14:20:38}}
> {{#101 TIME=2018-04-09 08:20:38.31; FORMATTED=9.4.2018 14:20:38}}
> {{#102 TIME=2018-04-09 08:20:38.31; FORMATTED=9.4.2018 14:20:38}}
> {{#200 TIME=2018-04-09 08:20:38.31; FORMATTED=9.4.2018 14:20:38}}
> {{[^TimestampsIssue.java]}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
