db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-4614) JDBC metadata gives incorrect lengths for timestamps
Date Thu, 02 Sep 2010 11:39:55 GMT

    [ https://issues.apache.org/jira/browse/DERBY-4614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12905481#action_12905481
] 

Knut Anders Hatlen commented on DERBY-4614:
-------------------------------------------

A couple comments to the parts of the patch that affects this issue:

1) I don't think we can change DRDAConstants.DRDA_TIMESTAMP_LENGTH
from 26 to 29. This constant needs to stay at 26 to ensure that newer
servers can talk to old clients after the DERBY-2602 changes. It is
not used by any of the meta-data calls, as far as I know, so I think
it is safe to leave this change out. You may want to run the
compatibility tests to verify that we don't break compatibility. See
java/testing/org/apache/derbyTesting/functionTests/tests/junitTests/compatibility/README.html
for details on how to set up and run these tests.

2) We have this code in ColumnMetaData.getScale():

    // We get the scale from the SQLDA as returned by DERBY, but DERBY does not return the
ANSI-defined
    // value of scale 6 for TIMESTAMP.
    //
    //   The JDBC drivers should hardcode this info as a short/near term solution.
    //
    if (types_[column - 1] == Types.TIMESTAMP) {
        return 6;
    }

    return sqlScale_[column - 1];

The patch changes this code to return 9 in the case of a timestamp,
which I think is fine, but I'm wondering if the special case for
timestamp could be removed now that we make the embedded driver return
9 from its getScale() method. I think the value in sqlScale_[column-1]
comes from the embedded driver, but we need to check that.

3) I see that the existing tests have been updated, and those changes
look fine to me. But do we also need new test cases to cover all the
changes listed in the functional spec? I see that the existing tests
cover these methods with the timestamp type:

    DatabaseMetaData.getTypeInfo()
    DatabaseMetaData.getProcedureColumns()
    DatabaseMetaData.getFunctionColumns()
    ResultSetMetaData.getColumnDisplaySize()
    ResultSetMetaData.getPrecision()
    ResultSetMetaData.getScale()

But I couldn't find that we test ParameterMetaData.getPrecision() and
ParameterMetaData.getScale() with timestamp anywhere. Do you think it
would be worthwhile to add tests for those two methods?

> JDBC metadata gives incorrect lengths for timestamps
> ----------------------------------------------------
>
>                 Key: DERBY-4614
>                 URL: https://issues.apache.org/jira/browse/DERBY-4614
>             Project: Derby
>          Issue Type: Bug
>          Components: SQL
>    Affects Versions: 10.6.1.0
>            Reporter: Rick Hillegas
>            Assignee: C.S. Nirmal J. Fernando
>         Attachments: derby-4614-1.diff, derby-4614-fs.html
>
>
> While looking into DERBY-2602, I noticed that Derby gives the wrong lengths for various
fields in the JDBC metadata for timestamps. I will attach a spec describing what I think should
be done to correct this.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message