db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "A B (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-1816) Client's ResultSet.getTime() on a SQL TIMESTAMP column loses the sub-second resolution and always has a milli-second value of zero.
Date Fri, 04 May 2007 20:58:15 GMT

     [ https://issues.apache.org/jira/browse/DERBY-1816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

A B updated DERBY-1816:
-----------------------

    Attachment: d1816_recycleCleanup_v1.patch

While looking into this issue I noticed that there are several methods in client/am/DateTime.java
which do the following two things:

  1) Take a "recyclable" Time, Timestamp, or Date object with the apparent
     intent of avoiding repeated creation of corresponding java.sql.* objects.

  2) Make use of "setXXX" methods that have been deprecated as of JDK 1.1.

As an example, see client/am/DateTime.timeBytesToTime(...).

That said, it looks like the "recyclable" objects are always null which makes the #1 code
pretty meaningless (this is confirmed by the fact that the code coverage results show the
relevant code is never executed).

I believe I have a fix for this Jira (DERBY-1816), but before working more with it I'm posting
d1816_recycleCleanup_v1.patch, which is a pre-patch that does the following:

  1) Replaces each of the recyclable Date, Time, and Timestamp arguments with
     a recyclable java.util.Calendar object.

  2) Modifies the relevant code to call methods on the recyclable Calendar object
     instead of on Date, Time, and Timestamp objects.  The benefit to doing this
     is that we are now using non-deprecated methods. 

Note that even with this patch we are still creating a new instance of Time/Timestamp/Date
for each method--the cleanup patch does not change that.  Instead, the cleanup patch adds
the instantiation of a new Calendar object (one per client/am/Cursor) and then (re-)uses that
object to replace the deprecated calls.  The goal here is not just to replace the deprecated
calls, though; I think that having a Calendar object will help resolve this particular Jira
(and maybe others), as well.

That said, I was reading through the comments on DERBY-889 and one thing I'm unsure about
is how/if timezones need to be handled in this code.  When writing the cleanup patch I took
a look at the embedded classes and, as far as I can tell, embedded creates a new instance
of GregorianCalendar (no timezone info specified) and creates the appropriate date/time object
from that (see for example the "newTimestamp()" method in iapi/types/SQLTimestamp, or the
"getTimeInMillis()" second in iapi/types/SQLDate).  The changes in d1816_recycleCleanup_v1.patch
are intended to mimic that behavior in client.

But it's quite possible that I've overlooked something, so I would appreciate any reviews/feedback
that anyone might have on this "cleanup" patch.

Note that d1816_recycleCleanup_v1.patch is not intended to change any functionality of the
client.  The hope for this patch is to keep all behavior the same (even the behavior that
is currently wrong) but to make it easier to fix the incorrect behavior with a subsequent
patch.

I ran suites.All and derbyall on SUSE Linux with ibm142 and there were no failures.

> Client's ResultSet.getTime() on a SQL TIMESTAMP column loses the sub-second resolution
and always has a milli-second value of zero.
> -----------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-1816
>                 URL: https://issues.apache.org/jira/browse/DERBY-1816
>             Project: Derby
>          Issue Type: Bug
>          Components: JDBC, Network Client
>    Affects Versions: 10.1.1.0, 10.1.2.1, 10.1.3.1, 10.2.1.6, 10.3.0.0
>            Reporter: Daniel John Debrunner
>            Priority: Minor
>         Attachments: d1816_recycleCleanup_v1.patch
>
>
> In embedded the java.sql.Time object returned from ResultSet.getTime() for a SQL TIMESTAMP
object has its millisecond value for the time portion equal to that for the java.sql.Timestamp
value.
> In client the millisecond time value for such a value is always set to zero.
> Note a Derby SQL TIME value has by definition resolution of only a second so its millisecond
 value is always zero,
> but java.sql.Time  is not a direct mapping to the SQL Type, it's a JDBC type, so when
converting from a SQL TIMESTAMP
> it should retain the precision.
> The new test lang.TimeHandlingTest has this assert code that shows the problem, one of
its calls will be commented out
> with a comment with this bug number.
>     private void assertTimeEqual(Time tv, Timestamp tsv)
>     {
>         cal.clear();
>         cal.setTime(tv);
>                 
>         int hour = cal.get(Calendar.HOUR_OF_DAY);
>         int min = cal.get(Calendar.MINUTE);
>         int sec = cal.get(Calendar.SECOND);
>         int ms = cal.get(Calendar.MILLISECOND);
>                         
>         // Check the time portion is set to the same as tv
>         cal.clear();
>         cal.setTime(tsv);
>         assertEquals(hour, cal.get(Calendar.HOUR_OF_DAY));
>         assertEquals(min, cal.get(Calendar.MINUTE));
>         assertEquals(sec, cal.get(Calendar.SECOND));
>         assertEquals(ms, cal.get(Calendar.MILLISECOND));      <<<<<<<<<<<<<
FAILS HERE
>     }

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


Mime
View raw message