[
http://issues.apache.org/jira/browse/DERBY-889?page=comments#action_12369883 ]
Bryan Pendleton commented on DERBY-889:
---------------------------------------
> the cal field can be set by other calls
I am continuing to struggle with the requirements for this issue, I'm afraid.
The ResultSet javadoc defines 4 overloads of getTimestamp():
- getTimestamp(int columnIndex)
- getTimestamp(int columnIndex, Calendar cal)
- getTimestamp(String columnName)
- getTimestamp(String columnName, Calendar cal)
The javadoc for the methods which take Calendar arguments say:
This method uses the given calendar to construct an appropriate
millisecond value for the
timestamp if the underlying database does not store timezone
information.
Which is pretty darn terse, unfortunately, and doesn't give us much guidance.
With the current unpatched code, I believe, the embedded driver was already not
using the
cached connection from the ConnectionChild if the caller passed in their own
Calendar
object (I will do more testing to confirm this). So I wasn't changing that
flow. The only
case where we use the cached Calendar object is when we don't already have a
Calendar object.
What EmbedResultSet..getTimestamp() does is to call the underlying
DataValueDescriptor's
getTimestamp() call, passing
- the Calendar object that the application gave us, if it gave us one, or
- the Calendar object that was cached in ConnectionChild, otherwise
Now, the SqlTime DataValueDescriptor already knows how to handle the case of a
NULL
Calendar object; in that case it allocates a fresh new Calendar object and
initializes it
with today's date and time, then fills in the time information from the
database column value.
This is the desired behavior, as I understand it, so all I was doing in the
patch was to
remove the cached Calendar object which was getting in the way of this behavior
(and
which wasn't providing any other useful behavior that I could see other than
the performance
optimization of not needing to allocate a new Calendar object).
However, I realize as a result of your comments that there are a number of
other issues here:
- how do DataValue objects other than SqlTime handle the Calendar object which
is passed
into the getTimestamp() method. I will need to research this some more.
- what is the intended semantic of the JDBC API when the client application
passes in a
Calendar object to getTimestamp() while fetching a value from a TIME field.
Is the
intended behavior:
- that we should preserve the date information in the client's Calendar
object?
- that we should overwrite the date information in the client's Calendar
object with
the current date and time?
Sigh. I've got a lot more things to study and learn about. That's a good thing
:) But if you can
provide any additional guidance in here, either from the SQL standard, or from
other areas,
that would be most helpful.
> 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
> Attachments: derby-889.diff
>
> 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
