Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <433462.1170862625897.JavaMail.jira@brutus>
Date: Wed, 7 Feb 2007 07:37:05 -0800 (PST)
From: "Saurabh Vyas (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-2287) JDBC meta data for precision and
 size is inconsistent and does not match JDBC specifications.
In-Reply-To: <8864359.1170437465494.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-2287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12470999 ] 

Saurabh Vyas commented on DERBY-2287:
-------------------------------------

After some investigation I found that getDigitPrecision() method  in DataTypeUtilities.java returns precision values which is inconsistent with that returned from metadata.properties. I tried following modification :

public static int getDigitPrecision(DataTypeDescriptor dtd) {
                int typeId = dtd.getTypeId().getJDBCTypeId();
                switch ( typeId )
                {
                      case Types.FLOAT:
                      case Types.DOUBLE:
                              //return TypeId.DOUBLE_PRECISION_IN_DIGITS;
                              return TypeId.DOUBLE_PRECISION;
                       case Types.REAL:
                             //return TypeId.REAL_PRECISION_IN_DIGITS;
                             return TypeId.REAL_PRECISION;
                      //Added case for Date & time data type
                      case Types.DATE:
                      case Types.TIME:
                      case Types.TIMESTAMP:
                            return dtd.getMaximumWidth();
                      default: return getPrecision(dtd);
              }

Then I tried the assert in crossCheckGetColumnRowAndResultSetMetaData() method of DatabaseMetaDataTest.java which  was failing for DATE , REAL and other data types :
          assertEquals("COLUMN_SIZE",  rsmdt.getPrecision(col), rs.getInt("COLUMN_SIZE"));

After above change, DATE & REAL data type are consistent in precision values and assert but I got assert for JAVACLASSNAME type. This I was not able to root cause.
Now I have two questions :
 - Is my approach for DATE & REAL data type correct
 - What is JAVACLASSNAME type & how to handle this.

> 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.