[
https://issues.apache.org/jira/browse/IGNITE-6135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16222503#comment-16222503
]
Vyacheslav Daradur commented on IGNITE-6135:
--------------------------------------------
Hi, [~ptupitsyn], [~NSAmelchev],
bq. This is how Ignite.NET maps uint to int, for example.
Are you talking about controlled overflow?
Do you mean that we must serialize {{Date.getDate()}} as a negative value in
case of the type is {{java.sql.Date}} and as a positive value in case of
{{java.util.Date}}?
There is the same case in the project: {{java.sql.Time}}, this type extends
{{java.util.Date}} and is serialized in the same way of representing as one
{{long}}.
This type has a separate constant in {{GridBinaryMarshaller}}.
1. Do we need to use the mixed approaches in the marshaller?
2. How should we do in the future with the subclasses types which can be
serialized in the same way as their superclasses?
> 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)
