Hi,

We're developing a new application and are reluctant to use surrogate keys for row identity, opting instead for the natural keys and so are using composite keys within Hibernate. We have decided this as we want to represent the data model independantly of any accessing framework.

We've started ok so far, but we have 2 problems (described below). We probably can get round them by treating each entity seperately in a DAO but would rather let Hibernate manage the one-to-many relationship.

Any advice / assistance would be greatly appreciated.

Regards


Problem 1 :
We have managed to get the <one-to-many> mappings working fine for selecting inserting and updating of child entities when performing the same on the parent, but deletes do not function as expected. Instead of a "delete" statement for the child entity Hibernate is generating an "update" statement setting all values to null for the mapped key column. I suspect this is because we are mapping a parent key to the partial key of the child ? Is this correct and if so is there any way around it ?



Mapping xml for Problem 1
--------------------------------
<hibernate-mapping default-cascade="all,delete-orphan">
<class name="app.dbaccess.bean.RUser" table="RUSER" lazy="false">

<id name="userId" column="USER_ID" type="string" unsaved-value="">
<generator class="assigned"/>
</id>

<property name="firstName" column="FIRST_NAME" type="string" unique="false"/>
<property name="surName" column="SURNAME" type="string" unique="false"/>
<property name="defaultLanguage" column="DEFAULT_LANGUAGE" type="string" unique="false"/>

<set name="offices" table="OFFICE_USER" lazy="false" inverse="false" cascade="all,delete-orphan">
<key column="USER_ID"/>
<one-to-many class="app.dbaccess.bean.officeUser" />
</set>

</class>

<class name="app.dbaccess.officeUser" table="OFFICE_USER" lazy="false">

<composite-id name="ouid" class="app.dbaccess.bean.officeUserId">
<key-property name="userId" type="string" column="USER_ID"/>
<key-property name="officeId" type="int" column="office_ID"/>
</composite-id>

<property name="role" column="ROLE" type="string" unique="false"/>

</class>
</hibernate-mapping>


Problem 2 :-

We tried a composite key parent to a composite key child (as below) but this fails with an initialization error. When we commented out the composite parent and inserted just a standard single column primary key. it worked fine. I suspect this is related to the first problem.


Mapping xml for Problem 2
---------------------------------
<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE hibernate-mapping
PUBLIC "-//Hibernate/Hibernate Mapping DTD//EN"
"http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">

<hibernate-mapping default-cascade="all,delete-orphan">
<class name="app.dbaccess.bean.TransportUnit" table="TRANSPORT_UNIT" lazy="false">

<!--composite-id name="tuid" class="app.dbaccess.bean.TransportUnitId">
<key-property name="transportUnitId" type="string" column="TRANSPORT_UNIT_ID"/>
<key-property name="plantId" type="int" column="PLANT_ID"/>
</composite-id-->

<id name="transportUnitId" column="TRANSPORT_UNIT_ID" type="string" unsaved-value="">
<generator class="assigned"/>
</id>

<property name="plantId" column="PLANT_ID" type="int" unique="false"/>
<property name="vehicleLicenseCode" column="VEHICLE_LICENSE_CODE" type="string" unique="false"/>
<property name="registeredTimestamp" column="REGISTERED_TIMESTAMP" type="calendar" unique="false"/>

<set name="tuDamages" table="TRANSPORT_UNIT_DAMAGES" lazy="false" inverse="false" cascade="all,delete-orphan">
<key column="TRANSPORT_UNIT_ID"/>
<one-to-many class="app.dbaccess.bean.TransportUnitDamage" />
</set>

</class>

<class name="app.dbaccess.bean.TransportUnitDamage" table="TRANSPORT_UNIT_DAMAGES" lazy="false">

<composite-id name="tuidDamage" class="app.dbaccess.bean.TransportUnitId">
<key-property name="transportUnitId" type="string" column="TRANSPORT_UNIT_ID"/>
<key-property name="plantId" type="int" column="PLANT_ID"/>
</composite-id>

<property name="picture01" column="PICTURE01" type="string" unique="false"/>
<property name="picture02" column="PICTURE02" type="string" unique="false"/>
<property name="picture03" column="PICTURE03" type="string" unique="false"/>

</class>
</hibernate-mapping>

By adding a table tag to your set you define a separate table for the relation. The tables should be

tableA -> tableA_B -> tableB

You have somewhat merged tableA_B and tableB in one table. I am not sure if this could be a reason for problems.

Have since managed to solve the 1st problem by inversing the relationship management (using inverse="true") on the set. My understanding is that when the relationship management is with the parent, then Hibernate will update the child removing the link (i.e. foreign key) and then delete the row. It will also so the same for inserts (so, an insert will insert the child row and then update the link which again is the foreign key from the parent to the child).

Inversing moves the relationship management to the child, so Hibernate does not update any link when the parent is deleted (as the parent does not now manage the relationship), but simply deletes.

I believe this is right, but stand to be corrected

The inverse=true is ok if it is indeed a bi-directional relationship. What about the fact when its unidirectional?

I ran into a similar problem which fortunately was fixed by specifying update=false on the key element of the set.

==
>>My understanding is that when the relationship management is with the parent, then Hibernate will update the child removing the link (i.e. foreign key) and then delete the row. It will also so the same for inserts (so, an insert will insert the child row and then update the link which again is the foreign key from the parent to the child).
==

I wonder if that's indeed the case. If a child gets deleted in a unidirectional relationship, all that's required is for it to be deleted from the database provided it has no other refereces to other parents which Hibernate ought to be able to detect (and does I think when delete-orphan is used as a cascade strategy)....