db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lance J. Andersen" <Lance.Ander...@Sun.COM>
Subject Re: [jira] Created: (DERBY-447) getBoolean() throws data conversion exception for DECIMAL type in J2ME/CDC/Foundation
Date Mon, 11 Jul 2005 19:31:13 GMT
The DatabaseMetaData method supportsConvert is used to validate what the 
scalar escape function CONVERT can be used for based on the 
driver/database combo.

The javadoc for the supportsConvert(arg1, arg2) should clarified a bit more.

As far as the name of the SQLTYPE for the Convert scalar function, 
drivers were doing this in an inconsistant manner.  adding the SQL_ 
prefix brings it in line with ODBC.  Drivers that do not support the 
SQL_ prefix (some drivers support with and without the prefix), will be 
required to support the prefix and to continue to optional support 
without the prefix. 

Is there an additional question here that i might have missed?

-lance

Dag H. Wanvik wrote:

>Hi,
>
>(Lance, see question to you below)
>
>  
>
>>>>>>"DJD" == Daniel John Debrunner <djd@debrunners.com> wrote:
>>>>>>            
>>>>>>
>DJD> 
>DJD> Dag H. Wanvik wrote:
>DJD> > DJD> There's some inconsistency here, the ResultSet getter methods are
>DJD> > DJD> converting from SQL data types to Java data types. This supportsConvert
>DJD> > DJD> method takes two arguments, both of which describe SQL data types.
>DJD> > 
>DJD> > Yes, you are right. Something for Lance to clarify :) 
>DJD> > But it would seem the no-args supportsConvert() should return false
>DJD> > until we add support for CONVERT.
>DJD> 
>DJD> And just to be clear, this is the JDBC CONVERT function from section C.5
>DJD> of JDBC 3.0, correct?
>
>Yes. 
>
>DJD> 
>DJD> I think there is some issue with CONVERT in JDBC 4.0, where the format
>DJD> of the second argument is changing, from INTEGER to SQL_INTEGER or
>DJD> something like that?
>
>Hmm.. I did a short check..  The DataBaseMetaData.supportsConvert has
>int (from java.sql.Types aka JDBC types/SQLtypes) for both arguments
>(both in JDBC 3.0 and early draft 4.0), which makes sense since the
>API speaks of describing the support/behavior of CONVERT, and this
>conversion all happens in the SQL domain.
>
>[On a side note: actually the Javadoc for supportsConvert speaks of
>(unqualified) CONVERT, without being explicit on this being the C.5
>escape JDBC CONVERT, not the SQL character set CONVERT, but I guess
>that's kind of obvious..?]
>
>Also, in both the JDBC 3.0 and 4.0 spec, the escape function CONVERT
>has SQLtype as the second argument, "value" being given as the first.
>
>The PreparedStatement "setter"/ ResultSet "getter" functions mappings,
>though, convert from and to Java types, given by the tables in the B
>appendix.
>
>I think the problem is that section 15.2.3.1 in the JDBC 4.0 spec
>(14.2.3.1 in 3.0) erroneously states that
>DataBaseMetaData.supportsConvert says ANYTHING about the mapping for
>getter methods. Interestingly, the corresponding section on conversion
>for *setter* methods makes no mention of
>DataBaseMetaData.supportsConvert (section 13.2.2.1 in 4.0 as well as
>in 3.0). Nor do the IN, OUT, INOUT descriptions.
>
>  
>
>>15.2.3.1 Data Type Conversions
>>The recommended ResultSet getter method for each JDBC type is shown
>>in TABLE B-6 on page B-210. This table also shows all of the
>>possible conversions that a JDBC driver may support. The method
>>DataBaseMetaData.supportsConvert(int fromType, int toType) returns
>>    
>>
>************************************ 
>  
>
>>true if the driver supports the given conversion.
>>    
>>
>
>Lance, do you agree this is wrong? If it is correct, please explain
>what I am missing here..!
>
>Notwhithstanding this, the Derby implementation of no-args
>DataBaseMetaData.supportsConvert() returns true, indicating we support
>C.5 CONVERT, which we do not AFAICS, and I suggest we make a JIRA for
>that.
>
>Dag
>  
>

Mime
View raw message