openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "B.J. Reed (JIRA)" <>
Subject [jira] Updated: (OPENJPA-645) Date millisecond precision lost for Informix IDS and SQLServer
Date Wed, 19 Aug 2009 12:52:14 GMT


B.J. Reed updated OPENJPA-645:

    Attachment: OPENJPA-645-1.0.x.patch

In 1.0.x, SQL Server has already been updated to allow the fractional portion of seconds to
be stored.  The OPENJPA-645-1.0.x patch does the same for InformixDictionary and removes the
flag from DBDictionary.

> Date millisecond precision lost for Informix IDS and SQLServer
> --------------------------------------------------------------
>                 Key: OPENJPA-645
>                 URL:
>             Project: OpenJPA
>          Issue Type: Bug
>          Components: jdbc
>            Reporter: Dinkar Rao
>            Priority: Minor
>         Attachments: OPENJPA-645-1.0.x.patch, patch-645.txt
> An entity has an attribute of type java.util.Date, annotated with @Temporal(TemporalType.TIMESTAMP):
> @Temporal(TemporalType.TIMESTAMP)
> public Date udate;
> This gets mapped in Informix to a column of type:
> and in SQLServer to 
> udate DATETIME
> When the udate attribute is assigned a value with millisecond precision, say "12:34:56:789",
OpenJPA chops off the millisecond fractional part when it generates the INSERT statement.
> In DBDictionary, for this type, we come to setDate() with the 'val' parameter set to
the correct java.util.Date value "12:34:56:789". (The millisecond value is stored in the (Gregorian.Date)
cdate.millis attribute of java.util.Date). setDate() then calls setTimestamp() - the last
else - with a new instance of java.sql.Timestamp:
> setTimestamp(stmnt, idx, new Timestamp(val.getTime()), null, col);
> java.sql.Timestamp is made up of 2 parts - a date part that stores the time upto seconds,
and a separate attribute, called nanos, that stores everything that is fractional of seconds.

> So the new Timestamp value that is sent to setTimestamp() has this:
> (Gregorian.Date) cdate = 12:34:56
> nanos = 789000000
> In setTimestamp() there is a check for supportsTimestampNanos. Because in the InformixDictionary
and SQLServer dictionaries this is set to false, the code then zeros out the nanos field:
> if (supportsTimestampNanos)
>     val.setNanos(nanos);
> else
>     val.setNanos(0);
> Consequently, all fractional seconds information is lost for these 2 database types from
the INSERT statement for this timestamp value. 
> The nanos field in java.sql.Timestamp does not really mean that only nanoseconds are
stored there - it means that any fractional value, after seconds  will be stored there.This
problem happens not only with the Date field in the entity, but also with java.util.Calendar
and java.sql.Timestamp. The solution is to always set the nanoseconds value in the (java.sql.Timestamp)val
field. The check for supportsTimestampNanos, as well as the flag itself, is not needed, because
both IDS and SQLServer do allow fractional seconds.
> Will attach a patch ASAP. Albert has reviewed the proposed solution.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message