What are the reasons to have the composite keys in a seperate class file?

The Hibernate in Action book only indicates that it makes composite foreign keys easier to read and access. Pages 334 - 336.

http://www.hibernate.org/hib_docs/reference/en/html_single/#mapping-declaration-compositeid
Indicates that seperate composite key class is " a much more convenient approach". But it does not state why.

Also, I have been trying to use the Criteria API with the composite keys in a seperate class and it seems that having the composite keys in seperate class makes querying on the information more difficult.

I am leaning on going back to having the composite key integrated in the main class.

Thank you for your suggestions and input,
David W.

If you have the composite key in CompositeUserType, you can write an approriate IdentifierGenerator and have them assigend automatically by Hibernate. With compoiste-id s you have to do this yourself.

Further more if you want to use cascading it's much more convenient if you can let Hibernate everything figure out instead of checking yourself for unsaved values in an Interceptor.

HTH
Ernst

Hmm... I don't beleive that answered my question.

Also, in our case I don't think that we can use an IdentifierGenerator as there is no pattern between the ables as to what fields are in the composite key. Some tables have upto 5 fields that make up the composite key. :( Legacy system.

Thx,
David