Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipselink-users] Possible or not?


Am 13.05.2015 um 18:57 schrieb Wim Jongman <wim.jongman@xxxxxxxxx>:

Hi Thomas,

Hi Wim,


We use DB2 for IBM i and I can remember we ran into similar issues. When looking at the properties for the driver [1] it looks like the last entry could help you? Not sure how this translate to z/OS

As far as i understand this option this is the wrong direction, I.e. Interpret binary as char.

I did hack up something that seems to work for at least basic sql select.
See:

But nobody did respond :-(

I think hibernate already has a feature that exactly provides the needed transformation, called column transformer:


Thanks for your answer and help.

With kind regards
Thomas


On Wed, Apr 1, 2015 at 2:48 PM, Tomas Kraus <tomas.kraus@xxxxxxxxxx> wrote:
What about using some safe encoding like base64 if you really don't want to relay for example on composite key of two bigint values? It will consume more space, it will slow things down but it should survive encoding changes.
For me using composite key of 2 bigints or int + bigint sounds like much better solution. Database operations will be much faster and you can use some field transformation in ORM to convert it to whatever you want.

Tomas

Dne 3/24/15 v 7:07 PM Thomas Meyer napsal(a):

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

_______________________________________________
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

_______________________________________________
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

Back to the top