db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <Richard.Hille...@Sun.COM>
Subject Re: setNull with BLOB column
Date Fri, 26 Jun 2009 13:44:31 GMT
Hi Dies,

I am not an expert on Toplink or its default datatype mappings for 
Derby. I think that LONGVARBINARY is a better mapping for byte[] and I 
would reserve BLOB as the mapping for columns which you really want to 
manipulate using the java.sql.Blob methods. It may be that BLOB is the 
default mapping because it can hold more bytes than the Derby 
hold up to 2,147,483,647 bytes while a Derby LONG VARCHAR FOR BIT DATA 
can only hold up to 32,700 bytes.

I don't know why Toplink is trying to put a LONGVARBINARY NULL into a 
column of type BLOB. The javadoc for PreparedStatement.setNull() states 
that the type of the NULL must be the type of the column. So I would 
expect that the code would do this instead:

  ps.setNull( n, java.sql.Types.BLOB );

Again, I'm not an expert on the O/R mapping frameworks, but I get the 
impression that it is fairly easy to tweak their vendor-specific 
datatype mappings. If your byte[] fields aren't longer than 32,700 bytes 
and you don't use the java.sql.Blob methods, then LONG VARCHAR FOR BIT 
DATA ought to work for you.

Hope this helps,

Dies Koper wrote:
> Hi,
> I have a JPA application and use Toplink as persistence provider.
> Toplink has a table creation option. It maps persistence fields of Java
> type byte[] (without @Lob annotation) to BLOB when using Derby.
> Is BLOB the recommended mapping for fields of type byte[]?
> I'm seeing the following issue with this because of the changes made in
> DERBY-1610:
> If I do not initialize the byte[] field (i.e. leave it null) and persist
> the entity object, Toplink calls setNull(n,
> java.sql.Types.LONGVARBINARY), leading to the following exception:
> Caused by: java.sql.SQLException: An attempt was made to get a data
> value of type 'LONGVARBINARY' from a data value of type 'BLOB'.
> 	at
> org.apache.derby.client.am.SQLExceptionFactory.getSQLException(Unknown
> Source)
> 	at org.apache.derby.client.am.SqlException.getSQLException(Unknown Source)
> 	at org.apache.derby.client.am.PreparedStatement.setNull(Unknown Source)
> 	at
> oracle.toplink.essentials.internal.databaseaccess.DatabasePlatform.setComplexParameterValue(DatabasePlatform.java:1438)
> From a google search I found a lot of discussions on the Derby mailing
> lists/issue tracker about adding such error checks and making them
> consistent, but I also had the idea some issues were left unresolved.
> Are there any plans to make changes to allow the above combination?
> Or would your opinion be that Toplink should change its default column
> type for byte[]?
> Thanks,
> Dies
> This is an email from Fujitsu Australia Software Technology Pty Ltd, ABN 27 003 693 481.
It is confidential to the ordinary user of the email address to which it was addressed and
may contain copyright and/or legally privileged information. No one else may read, print,
store, copy or forward all or any of it or its attachments. If you receive this email in error,
please return to sender. Thank you.
> If you do not wish to receive commercial email messages from Fujitsu Australia Software
Technology Pty Ltd, please email unsubscribe@fast.fujitsu.com.au

View raw message