Thanks for your analysis of the problem :-) There is some ongoing work on the SQLTypes that may solve the problem : http://bugzilla.exolab.org/show_bug.cgi?id=1130
Thomas Olausson wrote:
Remember I talked about DB2 truncating strings to 256 bytes?
http://www.mail-archive.com/[email protected]/msg10523.html
That is still the case, but a friend of mine has found a fix:
Apparently, there's a bug in Castor on how String gets mapped to varchar.
No matter if you map String to varchar or longvarchar, the PreparedStatement in Castor maps the
datatype to CHAR anyway. DB2 truncates CHARs to 256, even if they are VARCHARs in the database.
!!
A long story made short, to map a String correctly to varchar, this change of order has to be made in:
org.exolab.castor.jdo.engine.SQLTypes
new TypeInfo( java.sql.Types.VARCHAR, "varchar", java.lang.String.class ),
new TypeInfo( java.sql.Types.LONGVARCHAR, "longvarchar", java.lang.String.class ),
new TypeInfo( java.sql.Types.CHAR, "char", java.lang.String.class ),
Notice varchar is before char.
Otherwise, the type will be mapped to the first hist in the list, which is CHAR in the default distribution.
This method in the same class, needs to be worked on for that case:
public static int getSQLType( Class javaType )
{
for ( int i = 0 ; i < _typeInfos.length ; ++i ) {
if ( javaType.isAssignableFrom( _typeInfos[ i ].javaType ) )
return _typeInfos[ i ].sqlType;
}
return java.sql.Types.OTHER;
}
/Thomas
----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
--
Mickael Guessant
----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
