Hi all.

I'm a new Hibernate user. We recently chose Hibernate as our persistence Java provider. Our software house deeply relies on the manufacturing of DB-aware applications.

Now, the topic. After reading Hibernate's reference guide, some articles, and random things from Google (beloved Google :>), I think I've come to the conclusion that Hibernate likes auto-generated one-column keys and disregards "legacy" multi-column keys.

Actually, multi-column keys (or composite keys, as Hibernate's ref. calls them) are widespread in our older applications and in many of the already existing systems we integrate to.

I wonder : is Hibernate not really suited to that kind of design, being it a more modern and object-oriented persistence layer ?

Or is it just that we need to "get used" to Hibernate way of thinking ?

We used a custom persistence layer which mostly resembles Torque way of thinking. I never liked it 100%, and I like Hibernate's philosophy. I'm just worried about implementing legacy style DB design...

Any suggestion ?

Thanks

Giulio

If you have a clean composite key design, then Hibernate will work just as well. However, we tell people not to use natural and/or composite natural keys, as it is more work. In our experience, it also leads to more errors in the design and possibly difficult maintenance later on.

Thanks for your interest, Christian.

Indeed, I think that in your reference manual you are suggesting not to use "business" keys are primary keys. That sounds good to me, and looks like good logic. But still, sometimes, I think the old composite key design may suite.

And in that case I wonder... how does Hibernate know if an object with user-assigned is to be INSERTed or UPDATEd (e.g. use saveOrUpdate) ? I saw that there's an attribute in the XML descriptor, but it doesn't suite, because if the key is assigned (as in legacy data) and not generated you can't know if the object is persisted unless you have a flag on the object itself. So we should use save() and update()... and replicate lots of logic.

Should we then implement such method in a "father" class called Persistent or something like that ? Bad object design, I would say :)

I'm really interested in how Hibernate developers think about those things, because I feel like Hibernate's way is the right way and we're working the "old" way...

Thanks

Giulio

I have to work with composite id , too - I work so > 20 years
and I had problems with big and complicated databases

I had not problems, I'm sorry