[
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.
