ManyToOne composite key UnresolvableObjectException

scesbron · **Joined:** Thu Sep 04, 2003 8:23 am **Posts:** 368

Hi,

I have a many-to-one relation between two classes with a composite key on the one side.
Something like :

Code:

<class name="Bar" table="BAR">
  <id name="id">
  <many-to-one name="foo" class="Foo">
    <column name="ID_FOO1" />
    <column name="ID_FOO2" />
  </many-to-one>
  <property name="text"/>
</class>
</hibernate-mapping>

I have two questions about this :
- the order where I put ID_FOO1 and ID_FOO2 seems to be important. It seems that I must have the same order in Bar.hbm.xml and Foo.hbm.xml : is it exact ? (it seems normal for me but I just want a confirmation).

- More important : I have one case where ID_FOO1 is null but not ID_FOO2. In that case the database (SQLServer) guess that there is no foreign entity. Hibernate tries to load a Foo object with ID_FOO1=null and ID_FOO2="something" and throw a UnresolvableObjectException. Is this a bug or a behavioral choice ? In the second case why Hibernate did this choice ?

Thanx

Seb

scesbron · **Joined:** Thu Sep 04, 2003 8:23 am **Posts:** 368

In fact I did some deeper investigations and my problem is a little bit more tricky.
My bar class have two many-to-one associations with two classes with composite-keys and they share one column. Here is the sample code :
Bar.hbm.xml

Code:

<?xml version="1.0"?>
<!DOCTYPE hibernate-mapping PUBLIC
    "-//Hibernate/Hibernate Mapping DTD//EN"
    "http://hibernate.sourceforge.net/hibernate-mapping-2.0.dtd" >
    
<hibernate-mapping>

<class name="Bar" table="BAR">
  <id name="id">
    <generator class="increment" />
  </id>

  <many-to-one name="foo" class="Foo" update="false" insert="false">
    <column name="FOO_ID1" />
    <column name="FOO_ID2" />
  </many-to-one>
  <many-to-one name="other" class="Other" update="false" insert="false">
    <column name="FOO_ID1" />
    <column name="FOO_ID3" />
  </many-to-one>

  <property name="text"/>
</class>
</hibernate-mapping>

Foo.hbm.xml

Code:

<?xml version="1.0"?>
<!DOCTYPE hibernate-mapping PUBLIC
    "-//Hibernate/Hibernate Mapping DTD//EN"
    "http://hibernate.sourceforge.net/hibernate-mapping-2.0.dtd" >
    
<hibernate-mapping>

<class name="Foo" table="FOO">
  <composite-id>
    <key-property name="id1"/> 
    <key-property name="id2"/> 
  </composite-id>
  <property name="text"/>
</class>
</hibernate-mapping>

Other.hbm.xml

Code:

<?xml version="1.0"?>
<!DOCTYPE hibernate-mapping PUBLIC
    "-//Hibernate/Hibernate Mapping DTD//EN"
    "http://hibernate.sourceforge.net/hibernate-mapping-2.0.dtd" >
    
<hibernate-mapping>

<class name="Other" table="OTHER">
  <composite-id>
    <key-property name="id1"/> 
    <key-property name="id3"/> 
  </composite-id>
  <property name="text"/>
</class>
</hibernate-mapping>

I have a Bar instance associated with a Other instance (in my business logic, one bar instance could be associated with a Other instance OR a Foo instance). If I try to load it I have an UnresolvableObjectException.

Is there any solution to this problem ?

Thanx
Seb

emmanuel · **Posted:** Tue Jan 06, 2004 12:49 pm

You mean other than having 4 distinct columns, I don't think. To me (null, value) is a decent (pretty strange) composite key

scesbron · **Joined:** Thu Sep 04, 2003 8:23 am **Posts:** 368

epbernard wrote:

You mean other than having 4 distinct columns, I don't think. To me (null, value) is a decent (pretty strange) composite key

The problem is that Hibernate does not act like databases. SQLServer thinks that if one of the fk column is null the fk is null. Don' know how other db handle that but my dba told me that this is the most common case.

I went deeper in hibernate code and saw that my problem is in ComponentType.hydrate. When there is one non null column, we consider that the object is not null. Another approach should be to ensure that all pk columns are not null (don't seem so stupid).

seb

emmanuel · **Posted:** Tue Jan 06, 2004 1:34 pm

Oracle consider (null, value) as a decent PK AFAIK
It's a different capability from DBs.

scesbron · **Joined:** Thu Sep 04, 2003 8:23 am **Posts:** 368

epbernard wrote:

Oracle consider (null, value) as a decent PK AFAIK
It's a different capability from DBs.

In the earlier versions yes but not sure that this is always the case.
Just want to say that it would be great to have a behavior similar to the majority of the databases.

fridoo · **Posted:** Wed Mar 03, 2004 10:25 am

In our application we have lots of partial-null foreign keys which cause the problem described in this topic. I tried out the change suggested in ComponentType.hydrate() and this seems to do the job for me!

It would be really nice if the behavior of the many-to-one relationship with partial-null columns (reference is valid if either any or all columns are non-null) could be specified in the mapping.

As much as one might dislike composite identifiers and (partially) overlapping primary and/or foreign keys (personally I don't dislike it at all), it is a very common relational data modelling solution

scesbron · **Joined:** Thu Sep 04, 2003 8:23 am **Posts:** 368

Maybe you could post your code in a jira issue to submit this

fridoo · **Posted:** Thu Mar 04, 2004 4:12 am

Seb,

Just posted the JIRA issue. Of course, you own the credits for locating the changes needed in the ComponentType class

Cheers,

Frido

bird8088 · **Joined:** Fri Jan 30, 2004 3:01 pm **Posts:** 3

Aren't we discribing an optional many-to-one relationship. It appears that hibernate is demanding to load the related object even when one of the composite foreign keys are null. What I'm looking for is a way to discribe this relationship as optional in the mapping file. Is that possible? We have other relationships in our app where it is not optional, I would like to discribe both in the mapping file.

niallsmart · **Joined:** Fri Apr 02, 2004 1:20 pm **Posts:** 23

We are hitting the same problem -- anyone know the JIRA number?

It would also be nice to have this behaviour for non-composite keys also, we have some old legacy data in which the same column is re-used for different types of data depending on the context (yes, I know this is terrible) and we are getting UnresolveableObjectException when the data is not a valid foreign key.

<many-to-one unresolvable="exception|null"> would be very nice here.

Jabberwocky · **Joined:** Thu May 27, 2004 12:21 am **Posts:** 8

niallsmart wrote:

We are hitting the same problem -- anyone know the JIRA number?

It would also be nice to have this behaviour for non-composite keys also, we have some old legacy data in which the same column is re-used for different types of data depending on the context (yes, I know this is terrible) and we are getting UnresolveableObjectException when the data is not a valid foreign key.

<many-to-one unresolvable="exception|null"> would be very nice here.

Strongly agree with you, it would be really nice!

scesbron · **Joined:** Thu Sep 04, 2003 8:23 am **Posts:** 368

If you are interested by this feature you can vote for it on JIRA. It is issue HB-785 but Gavin closed it because he feels that this is a broken model problem.
Maybe if there is a lot of people interested by this feature the issue can be reopen

Seb

Jabberwocky · **Joined:** Thu May 27, 2004 12:21 am **Posts:** 8

scesbron wrote:

If you are interested by this feature you can vote for it on JIRA. It is issue HB-785 but Gavin closed it because he feels that this is a broken model problem.
Maybe if there is a lot of people interested by this feature the issue can be reopen

Seb

yes it's true this is a broken classic model problem, but sometimes we need "something strange"

wpfeiffe · **Posted:** Thu Jul 22, 2004 4:16 pm

Does anyone have a workaround on this? I'm using a model that has a TON of legacy code going against this composite key structure. Both Gavin's and my opinion that this is a broken model doesn't change that fact.

I've voted on this issue ( I guess I was number 6, not exactly big numbers).

We are going to investigate solving this with interceptors, but I wanted to see if anyone else has come up with a workaround first.