[Thomas Trostel]

I’d like to reference a table containing user names and passwords. The passwords are stored as encrypted binary objects using the JCE library. Now … when I use the export facility the generated classes want to become “Serializable” which technicaly is wrong. I would like to get the Blob object back and then get a byte[] array to check the password.

Here I tried replacing the mappings so the Java object uses Blob types and the hibernate mapping file uses the “blob” type. They should have internal classes for Clob and Blob objects now.

Everything works fine and the system initializes. When I try to retrieve a record and iterate I get

Caused by: java.sql.SQLException: Fail to convert to internal representation

Unfortunately the log isnt providing me enough information to track down this issue any farther.

Any ideas?

Thanks in advance.

[Riyad Kalla]

What DB server? What version? What driver and version are you using? Where did you grow up?

Just to clarify:
1) The column type is “Blob”?
2) What is your mapping entry in your hbm file for this field?
3) What is the argument and return type of the setter on the DTO that you are storing this value in when its loaded into the VM?

When I’ve done work with hibernate and Blob fields, I’ve never converted to bytes, just use “byte[]” as my type and when doing straight JDBC used “getBytes” instead of “getBlob” and its always worked (similar situation, I’m storing MD5 hashes).

[snpe]

try http://www.hibernate.org/73.html

regards

[Thomas Trostel]

Uh …

I’ll just make you a create script for the whole thing … that might be easier

create table USER_LOGIN(
USER_ID VARCHAR2(45) PRIMARY KEY not null,
USER_PASS RAW,
LAST_NAME VARCHAR2(30) not null,
FIRST_NAME VARCHAR2(30),
ACCESS_LEVEL VARCHAR2(1) not null,
ACCESS_TYPE VARCHAR2(1) not null,
VENDOR_ID VARCHAR2(10),
EMAIL_ID VARCHAR2(30) not null,
PHONE VARCHAR2(14),
USER_LOCK VARCHAR2(1) default ‘Y’ not null,
CREATE_BY VARCHAR2(30) not null,
CREATE_DATE DATE not null,
UPDATE_BY VARCHAR2(30),
UPDATE_DATE DATE,
PHONE_EXTN VARCHAR2(6),
PW_UPDATE_DT DATE)

and I use this mapping file

<?xml version=”1.0″ encoding=”UTF-8″?>
<!DOCTYPE hibernate-mapping PUBLIC “-//Hibernate/Hibernate Mapping DTD 2.0//EN” “http://hibernate.sourceforge.net/hibernate-mapping-2.0.dtd”&gt;
<hibernate-mapping>
<class name=”xxx.dao.UsersLogin” table=”USERS_LOGIN” schema=”xxx”>
<id name=”userId” column=”USER_ID” type=”long”>
<generator class=”native”/>
</id>
<property name=”userPass” column=”USER_PASS” type=”blob”/>
<property name=”lastName” column=”LAST_NAME” type=”string” />
<property name=”firstName” column=”FIRST_NAME” type=”string”/>
<property name=”accessLevel” column=”ACCESS_LEVEL” type=”string”/>
<property name=”accessType” column=”ACCESS_TYPE” type=”string”/>
<property name=”vendorId” column=”VENDOR_ID” type=”string”/>
<property name=”emailId” column=”EMAIL_ID” type=”string”/>
<property name=”phone” column=”PHONE” type=”string”/>
<property name=”userLock” column=”USER_LOCK” type=”string”/>
<property name=”createBy” column=”CREATE_BY” type=”string”/>
<property name=”createDate” column=”CREATE_DATE” type=”timestamp”/>
<property name=”updateBy” column=”UPDATE_BY” type=”string”/>
<property name=”updateDate” column=”UPDATE_DATE” type=”timestamp”/>
<property name=”phoneExtn” column=”PHONE_EXTN” type=”string”/>
<property name=”pwUpdateDt” column=”PW_UPDATE_DT” type=”timestamp”/>
</class>
</hibernate-mapping>

and the getters and setters look like this:

public Blob getUserPass() {
return this.userPass;
}

public void setUserPass(java.sql.Blob userPass) {
this.userPass = userPass;
}

Nothing fancy. Should I be using something else with RAW?

I looked at the link you had mentioned snpe .. thanks … I end up with the same results unfortunately.

Version info:

Database: Oracle 8
Driver: OJDBC-14 (Oracle Thin Driver)
Server: Tomcat 5.0.27

And I grew up in Massachusetts right in the middle of the state about three miles away from Mt Wachusett 😉

The code as it stands uses straight JDBC and uses getBytes also. I tried the byte[] avenue also with no luck. It might be that my issue is somewhere else. Unfortunately my other test program using another table works flawlessly … DOH … at least they either both succede or both fail. That would have been easier!

Thanks again.

[Thomas Trostel]

Actually it looks like some of the support in Hibernate for Oracle RAW columns is fragged.

Check this thread out:

http://forum.hibernate.org/viewtopic.php?p=2205909

DRATS … I was hoping it was going to be easier. It appears to be attempting to retrieve this value incorrectly inside of Hibernate.

[Riyad Kalla]

Ahh I see… nice job tracking that down.

Is it alright if I close this thread then? (you might want to add yourself to that bug for Hibernate to see when its fixed).

[Thomas Trostel]

Yes. Unfortunately this problem *seems* to be with Hibernate. I’ll keep messing with it and see if I can fix Hibernate. Someone should really sit down and talk with Larry Ellison about what “compliant” means reguarding JDBC drivers 😉

[Riyad Kalla]

hah, if you find a solution definately post back here for everyone. Thanks!

[Thomas Trostel]

Well … here’s a link to my thread on Hibernate’s forum if anyone would like to follow it:

http://forum.hibernate.org/viewtopic.php?t=932896

[snpe]

You search hibernate forum.There is more threads for oracle blob problem in hibernate

regards

[Thomas Trostel]

DOH … Actually its the Hibernate exporter function in MyEclipse. The generated metadata file seems to think the key field should be a long when its actually a string. When you change it to string everything works fine.

Well … now I understand in excruciating detail how Hibernate “hydrates” a persisted object!

[Riyad Kalla]

ttrostel,
Did someone send you some information on how to track down this problem? It would be helpful to our devs.

[Thomas Trostel]

You can call me Tom

I missed the part where the hibernate wizard asks you to identify the type on the key field. This seems a little strange since it can identify the key field to start with. Shouldn’t it come up with an inteligent default choice? Anyhow when I switch it from the default “long” to a String it seems to work fine. Its a handy tool for sure. Thank you for taking the time to work through this one with me.

[Riyad Kalla]

Tom, that’s great that you figured this out and we appreciate the feedback. I’ll send it along to our hibernate developer.

[support-jeff]

I missed the part where the hibernate wizard asks you to identify the type on the key field. This seems a little strange since it can identify the key field to start with. Shouldn’t it come up with an inteligent default choice?

Tom –
Excellent point. The existing wizard came from the original SQLExplorer plugin. I spent very little time on it for beta2. I am in the process of refactoring the whole damn thing now. I will add your comments as an enhancement request.

[Author]

Posts