Thomas,
Hi Doug,
I am not familiar with this specific data type but have extended EclipseLink many times to handle specialized data types from different databases.
Thanks for this link.
Most involve converting the value after it is returned in a JDBC result but some allow for more specialized conversion while the connection and result set are still available. If you can illustrate how to convert the column value using JDBC I can hopefully direct you to the best solution option in EclipseLink.
What I need for an select statement is basically: Select binary(column_name), another_column... Instead of Select column_name, another_column...
From an @entity class:
@Entity class MyClass { private byte[] columnName private BigDecimal anotherColumn }
Although column_name is defined as CHAR(12) it should be read as binary data. This can be done via DB2 function BINARY().
As far as I understand the converter options in above link, this is not possible with these, or is it?
See also my example implementation I did here:
What do you think about this approach?
With kind regards Thomas
Cheers,
Doug Hi,
We have some really old database tables consisting of a technical key and other dependent fields.
But there is a little problem with the key fields:
When the table was defined no binary data type was available in DB2 for z/OS so the key field was defined as CHAR(12) with codepage IBM-273.
As this codepage is a single byte codepage and as the data base system doesn't check the content of the character data, this key fields was actually used for binary data with 12 bytes lengths.
This was possible as all software accessing the database tables also did run in the same codepage as the field definition and no character conversion did ever happen...
When we now use the JDBC driver through EclipseLink a codepage conversion happens into UCS-2 or whatever Java uses internally and so destroying the original binary content!
The correct solution would be to alter the data type of all key fields containing technical keys to CHAR (12) FOR BIT DATA. With this data type definition JDBC/EclipseLink works correctly and does map the field content into byte[] array.
Mapping from CHAR(12) with codepage IBM-273 into a byte array via @Basic seems to result into a byte array, but this array seems to contain garbage and is only 5 bytes in lengths.
Sadly the data type alteration would have a severe impact on the running production system as the alter command needs certain conditions to work correctly...
So my question is:
Is it somehow possible to map a field of type CHAR(12) with codepage IBM-273, which is actually a CHAR(12) FOR BIT DATA field to a byte array with EclipseLink?
As far as I could see there seems to be no annotation to overwrite the concrete database type by casting it at least for reading with the binary() function.
I tried to use a converter but the converter mechanism is too late in the data transfer chain, the binary data was already destroyed here.
So it would be totally awesome if there would exist some way to do this cast/type override with JPA or an EclipseLink extension!
When no solution for the above problem exists, the only chance I see is to map all objects via named native queries and the SQL query map annotation. But this would somehow make an ORM a bit superfluous or doesn't it?
So I'm happy to here how to possibly deal with this situation from other users.
With kind regards
Thomas
_______________________________________________
eclipselink-users mailing list
eclipselink-users@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/eclipselink-users
|
