Hibernate version:3.0

I have a question about a composite key. If I use this kind of key (what is of course not recommended) I have approprieate properties inside my persistent object that store my composite key. Does additionally exist some associated object that store my coposite key?. Do I have to define class for object that store my key? I ask because this is how it works in JDO, that every composite key has related object.

And the second question is, if I don't define some id property in my persistent class, so id is store internally by Hibernate, how does Hibernate keep that id value. Is some object created for that id value.

thx...

In hibernate you have the option to declare composite-ids as mapped or unmapped. If you map them (using class="xxx") then getId() will return an instance of the class you specify. If you don't map them, then the properties are available directly from the main class. Have a look at section 5.1.5 of the ref docs for more info.

If you don't define an <id> element in your class mapping, then the mapping won't compile, so your other question is moot.

I'm interested in why you say composite keys are not recommended - after all it is perfectly valid to design your database with them.

From the ref docs, section 5.1.4, "id":

Some of us don't discourage their use, some do...

"Good" identifier must be unique, not null and immutable, generate identifier if natural identity is "Bad".

I know that defining <id> element im my class mapping file is necessary. But
I was not asking about id element im my mapping file but I was asking about how and where id is store in this case:

There are many problems if you are using the composite keys. They increase the complexity of your data access code.

E.g., if you update one part of the key, you must delete the old entity, and then persist the new entity - else will Hibernate insert the new object and keep the old, because they have defferent ID and from Hibernate sight they are 2 different objects.

If I have a parent child relationship I don't want to have to artificially create a primary key for the child records if their uniqueness can be determined by a composite key. This seems like bad design to me.

Composite keys (unless used as a link table) seem to be a bad design smell to me. There are good reasons not use composite keys if you can avoid them. I cannot see an advantage of using them for a parent-child relationship.

The positive side is that its great that hibernate allows us to use what ever we wish.

Earlier you asked:

In the CATEGORY_ID column... I guess that I'm missing the point of your question, because you can't have wanted to know that. Can you rephrase the question?