Re: Binding a char to PreparedStatement

[Craig Russell]

Hi, On Jul 20, 2005, at 8:49 AM, Michael Watzek wrote: Hi Andy, I extended the test program to make objects persistent using JPOX in addition to the JDBC test I described below: There is a persistence capable class having a field of type "char". There is a table having a single column of type "CHAR(1)". The orm metadata for this class specifies a field mapping from the "char" field to the "CHAR(1)" column. The orm column attribute "jdbc-type" is omitted. Thus, the JPOX default is used. When an object is made persistent using that mapping, then Derby throws error 22001 (see below). But if the mapping contains the orm column attribute "jdbc-type" setting it to "CHAR" explicitly, then Derby does not throw that error. Instead, pm.makePersistent succeeds. It seems, that JPOX does not default orm column attribute "jdbc-type" to "CHAR" if the field is of type "char" or "java.lang.Character". Instead, JPOX defaults to a numerical type, e.g. "INTEGER". Can you verify that? Craig, the spec specifies in chapter 18.5: "The jdbc-type attribute declares the type of the column in the database. This type is defaulted based on the type of the field being mapped." Does this mean, that an implementation may choose for an default? That was not the intent. The intent was that the JDBC type would be obvious. ;-) And the "obvious" jdbc-type for char and Character is CHAR. I'll raise this issue with the JDO experts to be sure. Another question: The TCK orm metadata does not specify column attribute "jdbc-type". Thus, implementations use their default when the TCK runs. Does it make sense, to add the jdbc type to all column attributes ensuring that the mapping fits to the database schema? I don't want to add the jdbc-type because it's not supposed to be needed for the simple TCK tests. I had thought that we should add jdbc-type for completeness, just to make sure the JDO implementation can handle it, but not in the general case. Craig Regards, Michael Hi Michael, we have a lot of derby errors "ERROR 22001: A truncation error was encountered trying to shrink CHAR 'XXX' to length 1." I've never seen one of these in our testcases, so we've got some difference in how the TCK is specifying things and how we've done it. I analysed the problem writing a little Java program that uses JDBC directly. The program inserts a row into a table having a single CHAR(1) column. The program uses a prepared statement and binds a Java character  to it using different methods: 1) PreparedStatement.setShort 2) PreparedStatement.setInt 3) PreparedStatement.setObject 4) PreparedStatement.setString What type is the Java type and what type is the DB column ? (and is there a jdbc-type specified in the MetaData?). Give an example of a Java field, its MetaData entry, and the RDBMS column type and we should be able to isolate this [OK, I could run the TCK and try to find one, but since you have these fresh in your memory its easier to ask you :-)] JPOX could use many different JDBC methods depending on what Java type and what RDBMS type so it depends on your situation. For example :- Java=char/Character, RDBMS="INTEGER", uses JDBC setInt() Java=char/Character, RDBMS="CHAR", uses JDBC setString() --  ------------------------------------------------------------------- Michael Watzek                  [EMAIL PROTECTED] Engineering GmbH mailto:[EMAIL PROTECTED]        Buelowstr. 66 Tel.:  ++49/30/235 520 36       10783 Berlin - Germany Fax.:  ++49/30/217 520 12       http://www.spree.de/ ------------------------------------------------------------------- Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!

smime.p7s
Description: S/MIME cryptographic signature