It's my fault. My co-worker's test case used a plain statement as opposed to a prepared statement.
For some reason we have to pad the char fields when we use a prepared statement (using Oracle's thin driver).
Thanks,
Bob
Bruce Snyder wrote:
This one time, at band camp, Bob Lee said:----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to
BL>Correct, "ID" is an SQL char, and "id" is a String.
BL>
BL>If it helps, "ID" is 10 characters. For example "123 " would work, BL>whereas "123" would not. However, it seems to work when using straight JDBC.
Bob,
AFAIK, (I may be incorrect) when accessing a database via it's client app
(oracle=sqlplus; postgresql=psql, etc), as a convenience feature, the
client usually handles any necessary padding automatically whereas via
JDBC this may or may not be the case depending on the implementation. What
database and JDBC drivers are you using?
If the data is going to be of variable length, in most cases a VARCHAR data
type is used and padding is not an issue.
One other thing to get around this might be the use of the LIKE
clause, although I haven't tested this specifically with a CHAR data
type. Depending on your situation, it may match too liberally.
IMO, Castor is working correctly in this situation. Below is the char->String algorithm from line #857 of
org.exolab.castor.jdo.engine.SQLTypes.java:
new TypeConvertorInfo( new SQLTypeConvertor( java.lang.Character.class, java.lang.String.class ) {
public Object convert( Object obj, String param ) {
return obj.toString();
}
} ),
Notice that there is no logic in addition to the implemenation of the
convert() method above.
Does anyone else have any input on this topic?
Bruce
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
