I'm having real trouble converting a mapping file to annotations for what is conceptually a fairly simple case. What I have is a PropertyDefinition class that can have 0 or more PropertyParams. The legacy database I am working with defines a composite primary key on the child table, consisting of the propertyId of the parent, and an index.

The mixture of composite keys, embeddable's, and list index columns is proving too much to grasp... I've read the documentation and looked for examples, but just haven't been able to work out the right combination of field types and annotations.

I'm sorry to come back to that old thread but I hope that Emmanuel is alerted and can reply.

Emmanuel, you said in 2003 that it will be in next release, but I don't think it is and what I see is that the <key-many-to-one> is still not well supported. Please corect me if I'm wrong.

About that issue, what I understand (from Hibernate in Action) is that we need to map one property for the primary key, and one many-to-one relationship with insertable=false and updateable=false.
But that has two drawbacks:
- either both properties must be set (duplication of code) or we need to flush and refresh the object (roundtrip to the database)
- the UML model is not very nice as the same attribute is seen both as an attribute and an association

Please, can you tell us if that issue is planned to be solved or not.

About the 'clean design is to use a surrogate key' response, I would like to explain a bit why it is not a good solution in some situations.
The situation where foreign key is part of the primary key is something that is often encountered in relational databases. It is what makes them both logically well designed and physically very efficient.

This is known as 'identifying relationship': an association can be part of the key as well as an attribute.

I can give a lot of examples. But basically, adding surrogate keys in those cases will:

- need an additional index (the primary key index + a unique index on the natural key)
That as a bad effect on performance (double the database work for inserts) and storage

- often need an additional join. When using composite natural keys for referential integrity, information is propagated to detail tables, without any denormalization. Using surrogate key, you often need to join to the master table to get the same information. That has a bad effect on performance.

- lower the possibilities to partition big tables (for oracle for example, you can't partition a unique index if the partition key is not part of the table primary key)

- at least for oracle, the optimizer will do better choices when using composite natural keys as it has statistics about all columns.

Of course, the workaround introducing a surrogate key for Hibernate is acceptable in small applications, but I'm currently dealing with a big application that manages large volume. I appreciate a lot the usage of Hibernate annotations to handle hundreds of business objects, but I can't ignore the performance constraints when building the data model.

I'll will appreciate a lot if we can have a vision of future improvements about that in hibernate.