[
https://issues.apache.org/jira/browse/CALCITE-5250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17597364#comment-17597364
]
Will Noble edited comment on CALCITE-5250 at 8/29/22 7:09 PM:
--------------------------------------------------------------
Here's an outtake from the traffic I was observing:
{{2022-08-26 17:22:30.384552: POST localhost:1895/jdbc}}
{{ connectionId:
04ca24ee-1d25-4a36-88ac-b1069363bf0e}}
{{ maxRowCount: -1}}
{{ maxRowsInFirstFrame: -1}}
{{ request: prepareAndExecute}}
{{ sql: 'SELECT CAST((''2017-01-01'') AS DATE) AS
`TEMP_Test_{_}1641592311{_}{_}0{_}`}}
{{ FROM `testv1`.`calcs` `calcs`}}
{{ HAVING (COUNT(1) > 0)'}}
{{ statementId: 0}}
{{2022-08-26 17:22:32.149329: 200 OK}}
{{ missingStatement: false}}
{{ response: executeResults}}
{{ results:}}
{{ - connectionId:
04ca24ee-1d25-4a36-88ac-b1069363bf0e}}
{{ firstFrame: null}}
{{ ownStatement: false}}
{{ response: resultSet}}
{{ rpcMetadata:}}
{{ response: rpcMetadata}}
{{ serverAddress:
wnoble.sfo.corp.google.com:1895}}
{{ signature:}}
{{ columns:}}
{{ - autoIncrement: false}}
{{ caseSensitive: true}}
{{ catalogName: null}}
{{ columnClassName: java.sql.Date}}
{{ columnName:
TEMP_Test_{_}1641592311{_}{_}0{_}}}
{{ currency: false}}
{{ definitelyWritable: false}}
{{ displaySize: 0}}
{{ label: TEMP_Test_{_}1641592311{_}{_}0{_}}}
{{ nullable: 0}}
{{ ordinal: 0}}
{{ precision: 0}}
{{ readOnly: true}}
{{ scale: 0}}
{{ schemaName: null}}
{{ searchable: false}}
{{ signed: true}}
{{ tableName: null}}
{{ type:}}
{{ id: 91}}
{{ name: DATE}}
{{ rep: PRIMITIVE_INT}}
{{ type: scalar}}
{{ writable: false}}
{{ cursorFactory:}}
{{ clazz: null}}
{{ fieldNames: null}}
{{ style: LIST}}
{{ parameters: []}}
{{ sql: 'SELECT CAST((''2017-01-01'') AS DATE)
AS `TEMP_Test_{_}1641592311{_}{_}0{_}`}}
{{ FROM `testv1`.`calcs` `calcs`}}
{{ HAVING (COUNT(1) > 0)'}}
{{ statementType: SELECT}}
{{ statementId: 0}}
{{ updateCount: -1}}
{{ rpcMetadata:}}
{{ response: rpcMetadata}}
{{ serverAddress: wnoble.sfo.corp.google.com:1895}}
{{2022-08-26 17:22:32.220078: POST localhost:1895/jdbc}}
{{ connectionId:
04ca24ee-1d25-4a36-88ac-b1069363bf0e}}
{{ fetchMaxRowCount: 100}}
{{ offset: 0}}
{{ request: fetch}}
{{ statementId: 0}}
{{2022-08-26 17:22:33.626139: 200 OK}}
{{ frame:}}
{{ done: true}}
{{ offset: 0}}
{{ rows:}}
{{ - - 1483228800000}}
{{ missingResults: false}}
{{ missingStatement: false}}
{{ response: fetch}}
{{ rpcMetadata:}}
{{ response: rpcMetadata}}
{{ serverAddress: wnoble.sfo.corp.google.com:1895}}
So the server is specifying {{DATE}} in the signature, then sending a value in
milliseconds in the results ({{{}1483228800000{}}} is {{2017-01-01}} UTC in
milliseconds since epoch). It seems the Calcite is assuming that dates are
always expressed in days, but jackson-databind (which does the serialization
for the JSON encoding) represents them in milliseconds. My hunch is that
whatever's doing the Protobuf encoding does not have the same issue, and that
there is a gap in the JSON encoding tests.
was (Author: wnoble):
Here's an outtake from the traffic I was observing:
{{2022-08-26 17:22:30.384552: POST localhost:1895/jdbc}}
{{ connectionId:
04ca24ee-1d25-4a36-88ac-b1069363bf0e}}
{{ maxRowCount: -1}}
{{ maxRowsInFirstFrame: -1}}
{{ request: prepareAndExecute}}
{{ sql: 'SELECT CAST((''2017-01-01'') AS DATE) AS
`TEMP_Test_{_}1641592311{_}{_}0{_}`}}
{{ FROM `testv1`.`calcs` `calcs`}}
{{ HAVING (COUNT(1) > 0)'}}
{{ statementId: 0}}
{{2022-08-26 17:22:32.149329: 200 OK}}
{{ missingStatement: false}}
{{ response: executeResults}}
{{ results:}}
{{ - connectionId:
04ca24ee-1d25-4a36-88ac-b1069363bf0e}}
{{ firstFrame: null}}
{{ ownStatement: false}}
{{ response: resultSet}}
{{ rpcMetadata:}}
{{ response: rpcMetadata}}
{{ serverAddress:
wnoble.sfo.corp.google.com:1895}}
{{ signature:}}
{{ columns:}}
{{ - autoIncrement: false}}
{{ caseSensitive: true}}
{{ catalogName: null}}
{{ columnClassName: java.sql.Date}}
{{ columnName:
TEMP_Test_{_}1641592311{_}{_}0{_}}}
{{ currency: false}}
{{ definitelyWritable: false}}
{{ displaySize: 0}}
{{ label: TEMP_Test_{_}1641592311{_}{_}0{_}}}
{{ nullable: 0}}
{{ ordinal: 0}}
{{ precision: 0}}
{{ readOnly: true}}
{{ scale: 0}}
{{ schemaName: null}}
{{ searchable: false}}
{{ signed: true}}
{{ tableName: null}}
{{ type:}}
{{ id: 91}}
{{ name: DATE}}
{{ rep: PRIMITIVE_INT}}
{{ type: scalar}}
{{ writable: false}}
{{ cursorFactory:}}
{{ clazz: null}}
{{ fieldNames: null}}
{{ style: LIST}}
{{ parameters: []}}
{{ sql: 'SELECT CAST((''2017-01-01'') AS DATE)
AS `TEMP_Test_{_}1641592311{_}{_}0{_}`}}
{{ FROM `testv1`.`calcs` `calcs`}}
{{ HAVING (COUNT(1) > 0)'}}
{{ statementType: SELECT}}
{{ statementId: 0}}
{{ updateCount: -1}}
{{ rpcMetadata:}}
{{ response: rpcMetadata}}
{{ serverAddress: wnoble.sfo.corp.google.com:1895}}
{{2022-08-26 17:22:32.220078: POST localhost:1895/jdbc}}
{{ connectionId:
04ca24ee-1d25-4a36-88ac-b1069363bf0e}}
{{ fetchMaxRowCount: 100}}
{{ offset: 0}}
{{ request: fetch}}
{{ statementId: 0}}
{{2022-08-26 17:22:33.626139: 200 OK}}
{{ frame:}}
{{ done: true}}
{{ offset: 0}}
{{ rows:}}
{{ - - 1483228800000}}
{{ missingResults: false}}
{{ missingStatement: false}}
{{ response: fetch}}
{{ rpcMetadata:}}
{{ response: rpcMetadata}}
{{ serverAddress: wnoble.sfo.corp.google.com:1895}}
So the server is specifying {{DATE}} in the signature, then sending a value in
milliseconds in the results ({{{}1483228800000{}}} is {{2017-01-01}} UTC in
milliseconds since epoch).
> Possible bug in date conversion
> -------------------------------
>
> Key: CALCITE-5250
> URL: https://issues.apache.org/jira/browse/CALCITE-5250
> Project: Calcite
> Issue Type: Bug
> Components: avatica
> Affects Versions: 1.22.0
> Reporter: Will Noble
> Assignee: Will Noble
> Priority: Minor
>
> In
> [DateFromNumberAccessor.getDate()|https://github.com/apache/calcite-avatica/blob/d88f91a3ed8590ab8cee0df5c53633b3d5e41c59/core/src/main/java/org/apache/calcite/avatica/util/AbstractCursor.java#L929]
> we multiply the number by {{{}MILLIS_PER_DAY{}}}. However, I'm observing
> that the integer values being sent over the wire (using the JsonHandler) are
> already expressed in milliseconds since epoch, as seen in
> [DateSerializer._timestamp()|https://github.com/FasterXML/jackson-databind/blob/b688919010a9147376dc435f742812afd5b46885/src/main/java/com/fasterxml/jackson/databind/ser/std/DateSerializer.java#L41]
> in jackson-databind (java.util.date.getTime returns time in milliseconds).
> So, the returned dates are super far in the future.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
