You are viewing a plain text version of this content. The canonical link for it is here.

Posted to issues@flink.apache.org by "Caizhi Weng (Jira)" <ji...@apache.org> on 2021/11/16 01:49:00 UTC

[jira] [Commented] (FLINK-24895) SqlTimestampSerializer#deserialize forgets to fully read from source when the record is null.

    [ https://issues.apache.org/jira/browse/FLINK-24895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17444221#comment-17444221 ] 

Caizhi Weng commented on FLINK-24895:
-------------------------------------

cc. [~twalthr]

> SqlTimestampSerializer#deserialize forgets to fully read from source when the record is null.
> ---------------------------------------------------------------------------------------------
>
>                 Key: FLINK-24895
>                 URL: https://issues.apache.org/jira/browse/FLINK-24895
>             Project: Flink
>          Issue Type: Bug
>          Components: API / Type Serialization System
>            Reporter: bx123
>            Priority: Minor
>
> As we support null Timestamp in this Serializer. In the 2 deserialize() methods, when we read the first long and get Long.MIN_VALUE, we directly return null and forget to read the next int which responds to nanos.
> If there is really a null Timestamp that has been serialized before, we may get wrong value when we deserialize the Object after this timestamp. So before return null,  source.skipBytesToRead(4) is needed to make the source in the right position.
> By the way, I find the copy(source, target) is implemented by deserialize the intermediate value, while its more efficient to just copy 12 bytes from source to target like target.write(source, 12).
>  



--
This message was sent by Atlassian Jira
(v8.20.1#820001)