Community
Participate
Working Groups
a field annotated with @Lob is mapped to the original datatype for this javatype (e.g. String to varchar) instead of clob. The same thing for byte[] to binary / blob. So one can not configure with @Lob if byte[] results in a blob or a meaningful type (binary) that can be used in QL (e.g. max, distinct, in, ...)
Can you please provide an source code example?
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.
*** Bug 317448 has been marked as a duplicate of this bug. ***
Deferred as part of 2.2.0 bug Scrub. Andreas, please comment if this needs to be targeted to a specific release.
scrubbing
Retargetting. Please vote for this bug or provide feedback to the list if this change is a problem.
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.
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. ;-)
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
The Eclipselink project has moved to Github: https://github.com/eclipse-ee4j/eclipselink
