This appears to be a bug in Toplink/Eclipselink that probably did not
show until Derby 10.4.x as there was a bug fix made to Derby and
previous versions of Java DB/Derby included with Glassfish was based
on 10.2.x.
Regards
Lance
On Jun 25, 2009, at 10:15 PM, Dies Koper wrote:
> Hi,
>
> I've run into an issue with an entity with a persistence field of type
> byte[] and JavaDB.
> The application worked on GF V2.0, but I get an error message on GF
> V2.1/V3 when I do not initialize the field (i.e. leave it null):
>
> 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)
>
> The problem, in a nutshell, seems to be:
>
> I use the default table generation function, so on JavaDB it creates a
> table with column type BLOB.
> When I create an entity and leave this field null, I get the error
> above
> when I flush it to the DB: the Derby driver complains that I try to
> put
> a Null of type Types.LONGVARBINARY into a column of type BLOB.
>
> I found a lot of discussions on the Derby mailing list, and it seems
> the
> error check was added intentionally between the Derby versions bundled
> with GF v2.0 and GFv2.1/V3.
>
> Why does GlassFish/Toplink choose BLOB as column type during table
> generation for JavaDB?
> From the Derby manual I understand that if it were mapped to LONG
> VARCHAR FOR BIT DATA, this problem would not occur.
>
> Thanks,
> Dies
>