[
https://issues.apache.org/jira/browse/DERBY-2602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Hillegas updated DERBY-2602:
---------------------------------
Attachment: derby-2602-01-ad-dontTruncate.diff
Attaching derby-2602-01-ad-dontTruncate.diff. This patch makes the client and
server exchange full nanosecond-precision timestamps as happens in the embedded
situation.
Although the regression tests pass, this patch is not ready for commit. I would
like to verify the compatibility of this patch with older clients.
Once this new behavior is committed, we may want to correct some metadata. For
instance, the maximum column width for timestamps is 26 characters today. That
is correct for timestamps which only have millisecond-precision, but for full
nanosecond-precision, the column width should be 29 characters. However, I
don't want to muddy this patch with that change because I suspect that it may
affect a lot of test results.
One of the tricky bits about coding this patch was tracking down the relevant
places in the code where the magic number 26 was used. I have replaced those
magic numbers with a constant. Hopefully that will help the next person who has
to study this logic.
Touches the following files:
M java/engine/org/apache/derby/iapi/types/TypeId.java
M java/engine/org/apache/derby/iapi/reference/DRDAConstants.java
Introduce constants to replace magic numbers.
---------------
M java/drda/org/apache/derby/impl/drda/AppRequester.java
M java/client/org/apache/derby/client/net/NetAgent.java
M java/client/org/apache/derby/client/net/NetDatabaseMetaData.java
M java/client/org/apache/derby/client/net/NetConnection.java
M java/client/org/apache/derby/client/am/Connection.java
M java/client/org/apache/derby/client/am/Agent.java
Create methods for determining whether the connection supports
nanosecond-precision timestamps.
---------------
M java/drda/org/apache/derby/impl/drda/DRDAConnThread.java
M java/drda/org/apache/derby/impl/drda/FdocaConstants.java
M java/client/org/apache/derby/client/net/Request.java
M java/client/org/apache/derby/client/am/Cursor.java
M java/client/org/apache/derby/client/am/DateTime.java
M java/client/org/apache/derby/client/net/NetStatementRequest.java
Logic to use full nanosecond-precision timestamps if the connection allows it.
---------------
M
java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/ParameterMappingTest.java
Updated this test to account for the corrected behavior.
> TIMESTAMP value is truncated when return to client
> ---------------------------------------------------
>
> Key: DERBY-2602
> URL: https://issues.apache.org/jira/browse/DERBY-2602
> Project: Derby
> Issue Type: Bug
> Components: Network Client
> Affects Versions: 10.3.1.4
> Reporter: Kathey Marsden
> Assignee: Rick Hillegas
> Priority: Minor
> Attachments: d2602.java, derby-2602-01-ad-dontTruncate.diff
>
>
> In ParameterMappingTest I see the following differences between embedded
> and client. Client is truncating the TIMESTAMP value. Look for this bug
> number in the test for reproduction.
> case java.sql.Types.TIMESTAMP:
> if (param == 2)
> if (usingEmbedded())
> assertEquals("2004-03-12 21:14:24.938222433",
> val.toString());
> else
> assertEquals("2004-03-12 21:14:24.938222",
> val.toString());
> else if (param == 3)
> if (usingEmbedded())
> assertEquals("2004-04-12 04:25:26.462983731",
> val.toString());
> else
> assertEquals("2004-04-12 04:25:26.462983",
> val.toString());
> break;
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
