[
http://issues.apache.org/jira/browse/DERBY-889?page=comments#action_12369352 ]
Bryan Pendleton commented on DERBY-889:
---------------------------------------
EmbedResultSet extends ConnectionChild. ConnectionChild has a private field
"cal" of type Calendar which it re-uses from call to call (see
ConnectionChild.getCal() ). This looks like a performance optimization of some
sort, but it has the effect that when we call getTimestamp() on a TIME column
in the embedded driver, the date portion of the returned timestamp will come
back with whatever date information happened to be lying around in
ConnectionChild's "cal" object.
Thus if getTimestamp(TIME) is the very first time that we make a
calendar-related call on this embedded result set, everything is fine, but if
the getTimestamp(TIME) call is made after some other call which has populated
the cached calendar object, we get the data value of that other call back in
our result.
So I think there is definitely an Embedded bug here, in addition to the Network
Client bug discussed in earlier comments.
One simple way to fix this is to have EmbedResultSet.getTimestamp() always
initialize the calendar with today's date and time:
Index: java/engine/org/apache/derby/impl/jdbc/EmbedResultSet.java
===================================================================
--- java/engine/org/apache/derby/impl/jdbc/EmbedResultSet.java (revision
383160)
+++ java/engine/org/apache/derby/impl/jdbc/EmbedResultSet.java (working copy)
@@ -1032,6 +1032,7 @@
if( cal == null)
cal = getCal();
+ cal.setTime(new java.util.Date());
return dvd.getTimestamp( cal);
} catch (StandardException t) {
Another possibility, since the underlying SqlTime.java code is prepared to
receive a NULL calendar object, is for EmbedResultSet.getTimestamp to skip the
optimization of trying to re-use the calendar object, and just allow
SqlTime.getTimestamp to allocate a new one:
Index: java/engine/org/apache/derby/impl/jdbc/EmbedResultSet.java
===================================================================
--- java/engine/org/apache/derby/impl/jdbc/EmbedResultSet.java (revision
383160)
+++ java/engine/org/apache/derby/impl/jdbc/EmbedResultSet.java (working copy)
@@ -1030,8 +1030,6 @@
if (wasNull = dvd.isNull())
return null;
- if( cal == null)
- cal = getCal();
return dvd.getTimestamp( cal);
} catch (StandardException t) {
Since I'm not really sure about the purpose of the cached Calendar object in
ConnectionChild.java, I'm not quite sure whether one or the other of the above
proposals
is better, or maybe there are other alternatives I should consider instead.
Comments, anyone?
> with client getTimestamp on a TIME column will print the date 1900-01-01
> instead of the current date
> -----------------------------------------------------------------------------------------------------
>
> Key: DERBY-889
> URL: http://issues.apache.org/jira/browse/DERBY-889
> Project: Derby
> Type: Bug
> Components: Network Client
> Versions: 10.1.2.1, 10.1.2.2, 10.2.0.0, 10.1.3.0
> Reporter: Kathey Marsden
> Assignee: Bryan Pendleton
>
> On client getTimestamp on a TIME column will print date 1900-01-01 instead
> of the current date like the embedded driver.
> To repro run the DERBY-877 repro without specifying a file.encoding
> java TestEnc derbynetclient
> [snip]
> COLUMN 2:TM TIME
> getString: 16:27:35
> getTimeStamp: 1900-01-01 16:27:35.0
> getTime: 16:27:35
> getDate Exception SQLSTATE:null (EXPECTED)
> With Embedded it prints the current date for getTimestamp
> java TestEnc derby
> COLUMN 2:TM TIME
> getString: 16:27:35
> getTimeStamp: 2006-01-28 16:27:35.0
> getTime: 16:27:35
> getDate Exception SQLSTATE:22005 (EXPECTED)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
