ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vladimir Ozerov <voze...@gridgain.com>
Subject Re: Why portable marshaller handle Date and Timestamp in the same way?
Date Tue, 06 Oct 2015 10:26:20 GMT
Yakov, this could work in .Net where you have real generics. But it will
not work in Java in general case due to type erasure - you simply cannot
infer the type.

Let's look closely to this:
Date      Java: 10^-3
Timestamp Java: 10^-9
DateTime  .Net: 10^-7

What we see here, is that mapping Java Date to .Net DateTime is alomst
certainly a bad thing because we loos too much data. But interoping between
Timestamp and DateTime is more or less sensible, we loose only 0.1-s of
microseconds.

I would suggest the following solution:
1) Fully decouple Date and Timestamp in Java. These are completely
different types from Java perspective, H2 perspective (see GridH2Date,
GridH2Timestamp), any data database perspective, etc..
2) Map .Net DateTime to Java Timestamp with warning about possible
precision loss.

Vladimir.

On Tue, Oct 6, 2015 at 1:08 PM, Yakov Zhdanov <yzhdanov@apache.org> wrote:

> 2015-10-06 12:45 GMT+03:00 Dmitriy Setrakyan <dsetrakyan@apache.org>:
>
> > On Tue, Oct 6, 2015 at 2:42 AM, Vladimir Ozerov <vozerov@gridgain.com>
> > wrote:
> >
> > > This doesn't answers the question. First, Java Timestamp has greater
> > > precision than .Net DateTime, so silent data loss could happen in this
> > case
> > > as well. Second, "use timestamp" is defined on class level. It means we
> > > cannot handle a class which have both Date and Timestamp fields.
> > >
> > > Looks like a bug and/or invalid design for me.
> > >
> >
> > Agree, current design is not ideal. Vladimir, do you have other
> > suggestions?
>
>
> how about writing at max precision possible (+ proper type ID) and
> interpreting binary data on read depending on (a) portable reader method
> call or (b) on actual field type.
>
> --Yakov
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message