-->
These old forums are deprecated now and set to read-only. We are waiting for you on our new forums!
More modern, Discourse-based and with GitHub/Google/Twitter authentication built-in.

All times are UTC - 5 hours [ DST ]



Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 4 posts ] 
Author Message
 Post subject: Request help with Foreign Key Mapping Problem
PostPosted: Thu Dec 15, 2005 5:23 pm 
Newbie

Joined: Thu Dec 15, 2005 3:09 pm
Posts: 4
I am having difficulty mapping multiple foreign keys in a single table. The way the problem is manifesting itself leads me to believe there should be a hibernate property setting somewhere that I could adjust, but I don't know where nor what to set it to. Any help in resolving this would be appreciated.

The table in question has 27 columns of various type including NUMBER, VARCHAR2, TIMESTAMP and one CLOB. I am unable to replicate the schema for the database table here and do not have access to it on this system. The following columns from the table are foreign keys relevant to this question:

Name Type Size
P_RELATOR NUMBER 19
P_RELATEE NUMBER 19
E_RELATOR NUMBER 19
E_RELATOR NUMBER 19

In a given record/object I will have exactly one relator and exactly one relatee. I do not know which type (P or E) of each I will have until the object is instantiated.

The hibernate mappings for these fields is as follows:

<!-- 1 -->
<many-to-one name="pRelator"
class="org.my.p.Default_P"
column="P_RELATOR_ID"
cascade="save-update" />

<!-- 2 -->
<many-to-one name="pRelatee"
class="org.my.p.Default_P"
column="P_RELATEE_ID"
cascade="save-update" />

<!-- 3 -->
<many-to-one name="eRelator"
class="org.my.e.Default_E"
column="E_RELATOR_ID"
cascade="save-update" />

<!-- 4 -->
<many-to-one name="eRelatee"
class="org.my.e.Default_E"
column="E_RELATEE_ID"
cascade="save-update" />

When persisting records to the database, E_Relators and E_Relatees seem to work fine. Their _objectID values are successfully stored in the table in the E_RELATOR_ID or E_RELATEE_ID foreign key fields as appropriate.

The P_RELATOR and P_RELATEE fields however do not get populated. Looking at the hibernate debug logs I can see that the parameter is being bound to null, even though examination with the debugger shows that corresponding value is anything but null. The lines from the logger read as follows:

DEBUG 2005.12.15 15:15:15 [main] (NullableType.javanullSafeSet:52) – binding null to parameter: 8
DEBUG 2005.12.15 15:15:15 [main] (NullableType.javanullSafeSet:52) – binding null to parameter: 9

Parameters 8 and 9 correspond to the P_RELATOR_ID and P_RELATEE_ID respectively.

HOWEVER:: When I comment out mappings #3 and #4 for E_RELATORs and E_RELATEEs the P_RELATORs and P_RELATEEs suddenly begin to work properly. (The E_RELATORS and E_RELATEES no longer work in this case as they have been commented out). This seems to indicate there is nothing wrong in the code or the mapping files per se., but rather the number of foreign key mappings that may be the problem.

In addition to the mappings listed above there are three additional x-many mappings in the file. These look as follows:

<set name="attributes" cascade="all-delete-orphan" lazy="true">
<key column="MY_RECORD_ID" />
<one-to-many class="org.my.attributes.DefaultAttribute" />
</set>

<set name="comments" cascade="all-delete-orphan" lazy="true">
<key column="MY_RECORD_ID" />
<one-to-many class="org.my.comments.DefaultComment" />
</set>

<set name="references"
table="MYRECORD_REFERENCES"
cascade="none"
lazy="true">
<key column="MY_RECORD_ID" />
<many-to-many
class="org.my.references.DefaultReference"
column="REF_ID" />
</set>

So I suspect it's a parameter setting somewhere. If someone could point me in the right direction I would very much appreciate it. If on the other hand I've done something totally stupid and someone could point that out to me I'd appreciate that as well.

Thanks,

John Kammer
-- Bit Systems Inc.

Hibernate version: 3.0.1

Full stack trace of any exception that occurs: N/A

Name and version of the database you are using: Oracle 10.1.0.4.0


Top
 Profile  
 
 Post subject: Still looking into the problem...
PostPosted: Fri Dec 16, 2005 2:55 pm 
Newbie

Joined: Thu Dec 15, 2005 3:09 pm
Posts: 4
Getting the Hibernate source matched up with the debugger has been a pain -- through no fault of hibernate, eclipse, or any of the other tools I'm using. [[ Long and irrelevant explanation not included here ]].

Looking further into this problem I can see that somewhere in the bowels of Hibernate the problem fields in my object are actually being nulled out before the object is being persisted to the database. I have no idea why this is and am trying to track it down. My Hibernate source does not appear to be exactly in sync with my hibernate jar file. I am working to correct that.

What I have been able to get to is that somewhere in the vacinity of the following, the fields I am interested in are getting nulled out before being persisted.

SessionImpl.persist (Object) :493
SessionImpl.persist (String, Object) :489
DefaultPersistEventListener.onPersist (PersistEvent) :38
DefaultPersistEventListener.onPersist (PersistEvent, Map) :84
DefaultPersistEventListener.entityIsTransient (PersistEvent, Map) :124
DefaultPersistEventListener(AbstractSaveEventListener).saveWithGeneratedID (Object, String, Object, SessionImplementor) :107

Just before getting to the spot indicated above is where the values are lost.

It'll probably take me a few days to get the current version of Hibernate and the corresponding source in to do further testing and analysis. If anyone has any ideas in the interim I would appreciate it.

-- John Kammer
-- BitSystems Inc.


Top
 Profile  
 
 Post subject: Re: Still looking into the problem...
PostPosted: Fri Dec 16, 2005 5:26 pm 
Newbie

Joined: Thu Dec 15, 2005 3:09 pm
Posts: 4
skykam wrote:
...

What I have been able to get to is that somewhere in the vacinity of the following, the fields I am interested in are getting nulled out before being persisted.

SessionImpl.persist (Object) :493
SessionImpl.persist (String, Object) :489
DefaultPersistEventListener.onPersist (PersistEvent) :38
DefaultPersistEventListener.onPersist (PersistEvent, Map) :84
DefaultPersistEventListener.entityIsTransient (PersistEvent, Map) :124
DefaultPersistEventListener(AbstractSaveEventListener).saveWithGeneratedID (Object, String, Object, SessionImplementor) :107


And a little bit further....

DefaultPersistEventListener(AbstractSaveEventListener).performSave (Object, Serializable, EntityPersister, boolean, Object, SessionImplementor) :158
DefaultPersistEventListener(AbstractSaveEventListener).performSaveOrReplicate (Object, Serializable, EntityPersister, boolean, Object, SessionImplementor) :223
SingleTableEntityPersister(BasicEntityPersister).setPropertyValues (Object, Object[], EntityMode) :2923
PojoTupilizer.setPropertyValues (Object, Object[]) :171
PojoTupilizer(AbstractTupilizer).setPropertyValues (Object, Object[]) :206

The method here appears to be where my values are being nulled out. I still do not entirely trust my version of the source code, but here's the method as I see it:

public void setPropertyValues (Object entity, Object [] values) throws HibernateException {
boolean setAll = !entityMetamodel.hasLazyProperties();
for ( int j=o; j < entityMetamodel.getPropertySpan (); j++ ) {
if ( setAll || vakues[j] != lazyPropertyInitializer.UNFETCHED_PROPERTY ) {
setters[j].set ( entity, values[j], getFactory() );
}
}
}


Top
 Profile  
 
 Post subject: Problem resolved
PostPosted: Mon Dec 19, 2005 4:34 pm 
Newbie

Joined: Thu Dec 15, 2005 3:09 pm
Posts: 4
Nevermind - - - I'm just a frickin' moron.

Problem was discovered in the business code. If anyone cares here's what was happening:

Business code allows for one RELATOR and one RELATEE. There are two possibilities for each: P-RELATORs, E-RELATORS and P-RELATEEs, E-RELATEEs.

The setter methods for these are such that when you set a P-Relator it nulls out any pre-existing E-Relator and vice versa. Ditto for he Relatees. The setters were not watching for a null arguments so setting a P-Relator to null would also set the E-Relator to null (as the code figured you were actually assigning a value to the P-Relator and you can't have both). The same is true for all these relationships.

Normally that wouldn't be a problem as you'd assign a value to the one you want and let the other get nulled out. You wouldn't generally assign null to these values directly. Except that hibernate does set them to null when it recovers nulls from the database. And in my case setting the E-Relator/Relatee to null was also resetting the P-Relator/Relatee.

Adjusted the setter methods so that they only null out their counterparts when the value they are being assigned is not null.

Life is good.


-- John Kammer
-- BITSystems Inc.


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 4 posts ] 

All times are UTC - 5 hours [ DST ]


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
© Copyright 2014, Red Hat Inc. All rights reserved. JBoss and Hibernate are registered trademarks and servicemarks of Red Hat, Inc.