Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <4836230.4901271100589948.JavaMail.jira@thor>
Date: Mon, 12 Apr 2010 15:29:49 -0400 (EDT)
From: "Rick Hillegas (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Updated: (DERBY-2602) TIMESTAMP value is truncated  when
 return to client
In-Reply-To: <17010421.1178134635553.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ 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