Bug 317597

Comment 1 Gordon Yorke 2010-06-22 11:13:22 EDT

Can you please provide an source code example?

Comment 2 Adrian Goerler 2010-07-14 08:34:38 EDT

I some case you need to store byte arrays with "raw data" for which binary comparison semantcis apply. A use case would be for example a binary GUID. 
Such data could be stored in a BINARY or VARBINARY column. BINARY and VARBINARY columns can be used in comparisons (WHERE, HAVING,  DISTINCT, ORDER BY) whereas BLOBs can't.

EclipseLink can very well deal with BINARY or VARBINARY columns. However, the forward mapper seems to always create a BLOB column for a Java byte array. My expectation would be that the forward mapper creates a BLOB column only if the byte array is annotated with @Lob and a BINARY or VARBINARY column otherwise.

As an example, I would expect the following mappings:

@Lob
byte[] image; -> BLOB

@Column(length=16)
byte[] guid; -> BINARY(16) or VARBINARY(16)

Unfortunately, the information whether an attribute is annotated with @Lob does not seem to be available to the forward mapper any longer.

Also, changing the mapping of 

@Column(length=16)
byte[] guid;

from BLOB to BINARY(16) would be incompatible.

Nevertheless, EclipseLink should provide a means to indicate that a byte array should be mapped to a non-BLOB column if desired. An option is to specify a column definition. But a column definition is not portable.

Alternatively, I could imagine to add a "value" member to the @Lob annotation (defaulting to "true", of course), allowing to indicate this:

@Column(length=16)
@Lob(false)
byte[] guid; -> BINARY(16)

But this would extend the standard.

I am not sure if the same issue is present for VARCHAR/CLOB.

Comment 3 Adrian Goerler 2010-07-16 09:46:35 EDT

*** Bug 317448 has been marked as a duplicate of this bug. ***

Comment 4 Peter Krogh 2010-11-10 11:20:29 EST

Deferred as part of 2.2.0 bug Scrub.  Andreas, please comment if this needs to be targeted to a specific release.

Comment 5 Peter Krogh 2011-06-20 13:57:02 EDT

scrubbing

Comment 6 Tom Ware 2011-08-23 11:06:08 EDT

Retargetting.  Please vote for this bug or provide feedback to the list if this change is a problem.

Comment 7 Rainer Schweigkoffer 2011-10-13 11:26:01 EDT

What is the present state of this bug ?

The currently more prominent aspect of it is, to my perception, that 

@Lob
<T> field;

gets mapped to the default type for <T>, e.g. VARCHAR instead of CLOB.

Comment 8 Tom Ware 2011-10-13 11:46:49 EDT

This bug has not currently been scheduled to be addressed in a particular release.

If I worked for a company that had committers on this project, I might see if I could interest them in fixing it. ;-)

Comment 9 Madhav Bhargava 2013-01-17 03:28:21 EST

Hi,

We are facing the same problem. Our JPA entities have to work with more than one database. On Sybase ASE CLOB and BLOB are not supported and therefore we cannot have something like:

@Lob
@Column(columnDefinition="CLOB")
private String tags;

This will work on DB's that support CLOB as a type but on Sybase ASE the corresponding type is TEXT.

So the assumption was that if i specify only @Lob on a field then for a String type it should map it to CLOB and for byte[] it should map it to a BLOB. That is not what is happening right now.

This is a huge concern for us and it would be great if someone could work on introducing this change.

Best Regards,
Madhav

Comment 10 Eclipse Webmaster 2022-06-09 10:08:51 EDT

The Eclipselink project has moved to Github: https://github.com/eclipse-ee4j/eclipselink