geoharp wrote:
http://www.hibernate.org/hib_docs/v3/reference/en/html_single/#components-compositeid
seems to set up some reasons for imbedded composite-keys.
huh ? it only shows external composite-keys.
Quote:
If i am on drugs could you point me to using them as seperate classes?
the docs you just pointed me to.
Quote:
and why does most of the documentation use imbedded ones.
huh ? no it does not. most of the docs uses single column/field id's. (not composite!)
Quote:
and doesn't the use of seperate classes cause foreign key issues?
huh!?
Quote:
Yes we have the worse kind of legacy db ... non tech people designed it and the imbedded compsite keys so far have handled everthing.
maybe you should tell me what you mean by "imbedded composite keys".
Quote:
I also have 40+ imbedded keys .... won't i have to change these?
depends what you actually mean.
Hibernate supports composite ids perfectly fine and these keys will of course be "embedded" into the same table as the data.....but in the object model it is much nicer to have the id encapsulated in its own class instead of being "flattend" out onto the entity.
Quote:
is there a rpo/con list to both approaches?
read about it here:
http://www.hibernate.org/hib_docs/v3/re ... ompositeidQuote:
PS I am not arguing just panicing that I change and then find out I can no longer support our data model
don't worry. hibernate supports more than what the tools generate...we just don't like to generate something we don't recommend people to do.
And embedded composite-ids into the domain model is not recommended.