[jira] [Comment Edited] (IGNITE-6135) java.sql.Date is serialized using OptimizedMarshaller

["Pavel Tupitsyn (JIRA)" <ji...@apache.org>]

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

Pavel Tupitsyn edited comment on IGNITE-6135 at 10/25/17 1:17 PM:
------------------------------------------------------------------

[~NSAmelchev], I don't think we should introduce another {{Date}} binary type in Ignite. Java 7 Date types situation is very confusing, let's avoid this mess in Ignite binary protocol.

Instead of introducing a new binary type, let's just write {{java.sql.Date}} as {{GridBinaryMarshaller.DATE}}, and convert back when deserializing user object fields.
This is how Ignite.NET maps {{uint}} to {{int}}, for example. This way user objects with {{sql.Date}} will work transparently, SQL will work on these fields as well. Let me know if you need more details.


was (Author: ptupitsyn):
[~NSAmelchev], I don't think we should introduce another {{Date}} binary type in Ignite.

{{java.sql.Date}} and {{java.util.Date}} are essentially the same (just a {{long}} value).
Instead of introducing a new binary type, let's just write {{java.sql.Date}} as {{GridBinaryMarshaller.DATE}}, and convert back when deserializing user object fields.
This is how Ignite.NET maps {{uint}} to {{int}}, for example. Let me know if you need more details.

> java.sql.Date is serialized using OptimizedMarshaller
> -----------------------------------------------------
>
>                 Key: IGNITE-6135
>                 URL: https://issues.apache.org/jira/browse/IGNITE-6135
>             Project: Ignite
>          Issue Type: Bug
>          Components: binary
>    Affects Versions: 2.1
>            Reporter: Valentin Kulichenko
>            Assignee: Amelchev Nikita
>             Fix For: 2.4
>
>
> For some reason, if an object has a field of {{java.sql.Date}}, it's serialized with {{OptimizedMarshaller}}. It should be a first class citizen, similar to {{java.util.Date}}.
> In addition, it's possible to write a field using builder like this:
> {code}
> builder.setField(name, val, java.util.Date.class)
> {code}
> where {{val}} is instance of {{java.sql.Date}}. This leads to an exception during deserialization, because {{java.util.Date}} would be expected.
> More context and code reproducing the issue can be found here: http://apache-ignite-users.70518.x6.nabble.com/JDBC-store-Date-deserialization-problem-td16276.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)