db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-2602) TIMESTAMP value is truncated when return to client
Date Mon, 12 Apr 2010 19:29:49 GMT

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


View raw message