[
https://issues.apache.org/jira/browse/IGNITE-6135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16218598#comment-16218598
]
Pavel Tupitsyn commented on IGNITE-6135:
----------------------------------------
[~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)
