[
https://issues.apache.org/jira/browse/DERBY-2287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12471010
]
Daniel John Debrunner commented on DERBY-2287:
----------------------------------------------
Getting them consistent I think is correct, but does the value being returned
match the JDBC 4 definition for precision?
Looking at the javadoc comments for the constants I would guess
DOUBLE_PRECISION_IN_DIGITS is the better match for JDBC 4, though I haven't
cross checked with JDBC 4.
// precision in number of bits
public static final int DOUBLE_PRECISION = 52;
// the ResultSetMetaData needs to have the precision for numeric data
// in decimal digits, rather than number of bits, so need a separate
constant.
public static final int DOUBLE_PRECISION_IN_DIGITS = 15;
> JDBC meta data for precision and size is inconsistent and does not match JDBC
> specifications.
> ---------------------------------------------------------------------------------------------
>
> Key: DERBY-2287
> URL: https://issues.apache.org/jira/browse/DERBY-2287
> Project: Derby
> Issue Type: Bug
> Components: JDBC, Network Client
> Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1, 10.1.3.1,
> 10.2.1.6, 10.2.2.0
> Reporter: Daniel John Debrunner
> Priority: Minor
>
> JDBC 4.0 has clarified the definitions of precision in the java doc for
> various methods that return precision or size. The concept of precision and
> size seems to be the same, just having different method or column names in
> various situations.
> Derby does not follow the JDBC 4 specifications consistently, for example -1
> is sometimes used to indicate not applicable, where JBDC 4 says NULL or 0.
> The precision of datetime columns is defined to be non-zero but in some
> situations Derby returns 0.
> jdbcapi.DatabaseMetaDataTest can show some of these issues, the test of
> getColumns() should compare the information in the COLUMN_SIZE column to the
> ResultSetMetaData getPrecision() method for the same column. The comparisions
> are not made currently because the number of mismatches is high. [this code
> is not yet committed].
> Existing application impact as Derby applications may have been relying on
> the old incorrect & inconsistent behaviour.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
