db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dag H. Wanvik" <Dag.Wan...@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 21:27:22 GMT

Hi Lance,

>>>>> "LJA" == Lance J Andersen <Lance.Andersen@Sun.COM> wrote:
LJA> 
LJA> The DatabaseMetaData method supportsConvert is used to validate what the 
LJA> scalar escape function CONVERT can be used for based on the 
LJA> driver/database combo.
LJA> 
LJA> The javadoc for the supportsConvert(arg1, arg2) should clarified
LJA> a bit more.

Agreed.

LJA> 
LJA> As far as the name of the SQLTYPE for the Convert scalar function, 
LJA> drivers were doing this in an inconsistant manner.  adding the SQL_ 
LJA> prefix brings it in line with ODBC.  Drivers that do not support the 
LJA> SQL_ prefix (some drivers support with and without the prefix), will be 
LJA> required to support the prefix and to continue to optional support 
LJA> without the prefix. 
LJA> 
LJA> Is there an additional question here that i might have missed?

Yes, sorry I wasn't clear enough. The question concerns the description
in section 15.2.3.1 in the JDBC 4.0 spec, which describes the
conversions performed by the ResultSet "getter" methods. These
conversions are described in appendix B-2, but the spec also states:

"The method DataBaseMetaData.supportsConvert(int fromType, int toType)
returns true if the driver supports the given conversion."

The point is, this conversion (the "getter conversion") is another
(kind of) conversion than that performed by the CONVERT scalar
function, and thus the reference to supportsConvert in 15.2.3.1 above
is not correct? 

The signature from "getter" methods is essentially "from: SQLtype to:
Java type", whereas the signature for CONVERT is "from: SQLtype, to:
SQLtype", right?

Perhaps there should have been additional DatabaseMataData methods to
allow querying what kind of conversions are supported for "getters"
(from SQLtype to Java types) (and vice versa for setters)? 

Dag


LJA> 
LJA> -lance
LJA> 
LJA> Dag H. Wanvik wrote:
LJA> 
LJA> >Hi,
LJA> >
LJA> >(Lance, see question to you below)
LJA> >
LJA> >  
LJA> >
LJA> >>>>>>"DJD" == Daniel John Debrunner <djd@debrunners.com>
wrote:
LJA> >>>>>>            
LJA> >>>>>>
LJA> >DJD> 
LJA> >DJD> Dag H. Wanvik wrote:
LJA> >DJD> > DJD> There's some inconsistency here, the ResultSet getter methods
are
LJA> >DJD> > DJD> converting from SQL data types to Java data types. This supportsConvert
LJA> >DJD> > DJD> method takes two arguments, both of which describe SQL data
types.
LJA> >DJD> > 
LJA> >DJD> > Yes, you are right. Something for Lance to clarify :) 
LJA> >DJD> > But it would seem the no-args supportsConvert() should return false
LJA> >DJD> > until we add support for CONVERT.
LJA> >DJD> 
LJA> >DJD> And just to be clear, this is the JDBC CONVERT function from section C.5
LJA> >DJD> of JDBC 3.0, correct?
LJA> >
LJA> >Yes. 
LJA> >
LJA> >DJD> 
LJA> >DJD> I think there is some issue with CONVERT in JDBC 4.0, where the format
LJA> >DJD> of the second argument is changing, from INTEGER to SQL_INTEGER or
LJA> >DJD> something like that?
LJA> >
LJA> >Hmm.. I did a short check..  The DataBaseMetaData.supportsConvert has
LJA> >int (from java.sql.Types aka JDBC types/SQLtypes) for both arguments
LJA> >(both in JDBC 3.0 and early draft 4.0), which makes sense since the
LJA> >API speaks of describing the support/behavior of CONVERT, and this
LJA> >conversion all happens in the SQL domain.
LJA> >
LJA> >[On a side note: actually the Javadoc for supportsConvert speaks of
LJA> >(unqualified) CONVERT, without being explicit on this being the C.5
LJA> >escape JDBC CONVERT, not the SQL character set CONVERT, but I guess
LJA> >that's kind of obvious..?]
LJA> >
LJA> >Also, in both the JDBC 3.0 and 4.0 spec, the escape function CONVERT
LJA> >has SQLtype as the second argument, "value" being given as the first.
LJA> >
LJA> >The PreparedStatement "setter"/ ResultSet "getter" functions mappings,
LJA> >though, convert from and to Java types, given by the tables in the B
LJA> >appendix.
LJA> >
LJA> >I think the problem is that section 15.2.3.1 in the JDBC 4.0 spec
LJA> >(14.2.3.1 in 3.0) erroneously states that
LJA> >DataBaseMetaData.supportsConvert says ANYTHING about the mapping for
LJA> >getter methods. Interestingly, the corresponding section on conversion
LJA> >for *setter* methods makes no mention of
LJA> >DataBaseMetaData.supportsConvert (section 13.2.2.1 in 4.0 as well as
LJA> >in 3.0). Nor do the IN, OUT, INOUT descriptions.
LJA> >
LJA> >  
LJA> >
LJA> >>15.2.3.1 Data Type Conversions
LJA> >>The recommended ResultSet getter method for each JDBC type is shown
LJA> >>in TABLE B-6 on page B-210. This table also shows all of the
LJA> >>possible conversions that a JDBC driver may support. The method
LJA> >>DataBaseMetaData.supportsConvert(int fromType, int toType) returns
LJA> >>    
LJA> >>
LJA> >************************************ 
LJA> >  
LJA> >
LJA> >>true if the driver supports the given conversion.
LJA> >>    
LJA> >>
LJA> >
LJA> >Lance, do you agree this is wrong? If it is correct, please explain
LJA> >what I am missing here..!
LJA> >
LJA> >Notwhithstanding this, the Derby implementation of no-args
LJA> >DataBaseMetaData.supportsConvert() returns true, indicating we support
LJA> >C.5 CONVERT, which we do not AFAICS, and I suggest we make a JIRA for
LJA> >that.
LJA> >
LJA> >Dag
LJA> >  
LJA> >
LJA> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
LJA> <html>
LJA> <head>
LJA>   <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
LJA>   <title></title>
LJA> </head>
LJA> <body bgcolor="#ffffff" text="#000000">
LJA> The DatabaseMetaData method supportsConvert is used to validate what
LJA> the scalar escape function CONVERT can be used for based on the
LJA> driver/database combo.<br>
LJA> <br>
LJA> The javadoc for the supportsConvert(arg1, arg2) should clarified a bit
LJA> more.<br>
LJA> <br>
LJA> As far as the name of the SQLTYPE for the Convert scalar function,
LJA> drivers were doing this in an inconsistant manner.&nbsp; adding the SQL_
LJA> prefix brings it in line with ODBC.&nbsp; Drivers that do not support the
LJA> SQL_ prefix (some drivers support with and without the prefix), will be
LJA> required to support the prefix and to continue to optional support
LJA> without the prefix.&nbsp; <br>
LJA> <br>
LJA> Is there an additional question here that i might have missed?<br>
LJA> <br>
LJA> -lance<br>
LJA> <br>
LJA> Dag H. Wanvik wrote:<br>
LJA> <blockquote cite="mid0IJB008TKZLK4E@epost-mail1.sweden.sun.com"
LJA>  type="cite">
LJA>   <pre wrap="">Hi,
LJA> 
LJA> (Lance, see question to you below)
LJA> 
LJA>   </pre>
LJA>   <blockquote type="cite">
LJA>     <blockquote type="cite">
LJA>       <blockquote type="cite">
LJA>         <blockquote type="cite">
LJA>           <blockquote type="cite">
LJA>             <pre wrap="">"DJD" == Daniel John Debrunner <a class="moz-txt-link-rfc2396E"
href="mailto:djd@debrunners.com">&lt;djd@debrunners.com&gt;</a> wrote:
LJA>             </pre>
LJA>           </blockquote>
LJA>         </blockquote>
LJA>       </blockquote>
LJA>     </blockquote>
LJA>   </blockquote>
LJA>   <pre wrap=""><!---->DJD&gt; 
LJA> DJD&gt; Dag H. Wanvik wrote:
LJA> DJD&gt; &gt; DJD&gt; There's some inconsistency here, the ResultSet getter
methods are
LJA> DJD&gt; &gt; DJD&gt; converting from SQL data types to Java data types.
This supportsConvert
LJA> DJD&gt; &gt; DJD&gt; method takes two arguments, both of which describe
SQL data types.
LJA> DJD&gt; &gt; 
LJA> DJD&gt; &gt; Yes, you are right. Something for Lance to clarify :) 
LJA> DJD&gt; &gt; But it would seem the no-args supportsConvert() should return
false
LJA> DJD&gt; &gt; until we add support for CONVERT.
LJA> DJD&gt; 
LJA> DJD&gt; And just to be clear, this is the JDBC CONVERT function from section C.5
LJA> DJD&gt; of JDBC 3.0, correct?
LJA> 
LJA> Yes. 
LJA> 
LJA> DJD&gt; 
LJA> DJD&gt; I think there is some issue with CONVERT in JDBC 4.0, where the format
LJA> DJD&gt; of the second argument is changing, from INTEGER to SQL_INTEGER or
LJA> DJD&gt; something like that?
LJA> 
LJA> Hmm.. I did a short check..  The DataBaseMetaData.supportsConvert has
LJA> int (from java.sql.Types aka JDBC types/SQLtypes) for both arguments
LJA> (both in JDBC 3.0 and early draft 4.0), which makes sense since the
LJA> API speaks of describing the support/behavior of CONVERT, and this
LJA> conversion all happens in the SQL domain.
LJA> 
LJA> [On a side note: actually the Javadoc for supportsConvert speaks of
LJA> (unqualified) CONVERT, without being explicit on this being the C.5
LJA> escape JDBC CONVERT, not the SQL character set CONVERT, but I guess
LJA> that's kind of obvious..?]
LJA> 
LJA> Also, in both the JDBC 3.0 and 4.0 spec, the escape function CONVERT
LJA> has SQLtype as the second argument, "value" being given as the first.
LJA> 
LJA> The PreparedStatement "setter"/ ResultSet "getter" functions mappings,
LJA> though, convert from and to Java types, given by the tables in the B
LJA> appendix.
LJA> 
LJA> I think the problem is that section 15.2.3.1 in the JDBC 4.0 spec
LJA> (14.2.3.1 in 3.0) erroneously states that
LJA> DataBaseMetaData.supportsConvert says ANYTHING about the mapping for
LJA> getter methods. Interestingly, the corresponding section on conversion
LJA> for *setter* methods makes no mention of
LJA> DataBaseMetaData.supportsConvert (section 13.2.2.1 in 4.0 as well as
LJA> in 3.0). Nor do the IN, OUT, INOUT descriptions.
LJA> 
LJA>   </pre>
LJA>   <blockquote type="cite">
LJA>     <pre wrap="">15.2.3.1 Data Type Conversions
LJA> The recommended ResultSet getter method for each JDBC type is shown
LJA> in TABLE B-6 on page B-210. This table also shows all of the
LJA> possible conversions that a JDBC driver may support. The method
LJA> DataBaseMetaData.supportsConvert(int fromType, int toType) returns
LJA>     </pre>
LJA>   </blockquote>
LJA>   <pre wrap=""><!---->************************************ 
LJA>   </pre>
LJA>   <blockquote type="cite">
LJA>     <pre wrap="">true if the driver supports the given conversion.
LJA>     </pre>
LJA>   </blockquote>
LJA>   <pre wrap=""><!---->
LJA> Lance, do you agree this is wrong? If it is correct, please explain
LJA> what I am missing here..!
LJA> 
LJA> Notwhithstanding this, the Derby implementation of no-args
LJA> DataBaseMetaData.supportsConvert() returns true, indicating we support
LJA> C.5 CONVERT, which we do not AFAICS, and I suggest we make a JIRA for
LJA> that.
LJA> 
LJA> Dag
LJA>   </pre>
LJA> </blockquote>
LJA> </body>
LJA> </html>
LJA> 
-- 
Dag H. Wanvik
Sun Microsystems, Web Services, Database Technology Group
Haakon VII gt. 7b, N-7485 Trondheim, Norway
Tel: x43496/+47 73842196, Fax:  +47 73842101

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
NOTICE: This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged
information. Any unauthorized review, use, disclosure or distribution
is prohibited. If you are not the intended recipient, please contact
the sender by reply email and destroy all copies of the original
message.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 

Mime
View raw message