Say I have class C, which is a children class of class P, and the class P contains a composite key, persisted as class compID, where the identifier of compID is a identity key.

I have a problem

the foreign key of C references P is also composite. I have to first instantiate compID, and assign it to P. After that, I reference P from C.

If I persist C first, one of the the foreign key in C reference to P, which is P's identity key, would not be correct since it is not generated yet before P is persisted.

If I persist P first, the value of the foreign key in C reference to P, which is P's identity key, would also not be correct.

What is the correct way of doing so? I read the document, from 6.4 As composite Identifiers,

"Since a composite identifier must be assigned to the object before saving it, we can't use unsaved-value to distinguish between newly instantiated instancesand instances saved in a previous session. You should instead implmenet Interceptor.isUnsaved() if you wish to use saveOrUpdate() or cascading save/update."

Where can I find more detail explanation of the above paragraph? or sample code illustrating it? I'm not sure whether it is the cause of the problem.

Hi, I've been working with compound keys a bit lately. Here's what may help you.

If you can change the database, then do so, as it will make it all so much easier.
If you can't,
Check out the Classes Inner, Middle and Outer, in the test.src directory of the distribution.

Make sure your key classes implement a good hashcode/equals.

One more thing- as far as the unsaved-value problem. Hibernate can't detect a new vs. existing entity in the database when you use a composite key. In 2.1 you can get around this by telling hibernate to look at a Timestamp field. It's in the docs. Something like this:

<timestamp column="LAST_UPDATED" unsaved-value="null" >

This allows hibernate to know whther to fire an insert vs update, since it can't tell based on the key.

James

Thx jlawmi! I will try your suggestion!

Correct, I prefer using <version> which is far more safe than <timestamp>