Hi,
I am using Hibernate 3.1.2 with Hibernate Annotations. My question is that
does hibernate supports UNIDIRECTIONAL ONE TO MANY relationship? If yes then can anyone provide me the little code for it using annotations. Just to clarify i have two tables Department and Employee having one to many relationship. I want to have employee collection in employee model but dont want to add Department in Employee Model. I am quite new to hibenate association and i have read a lot of documentation but not getting clear about actual semantics to acheive this.

My second question is about cascading. I want to have cascading on save, update,refresh and merge but not on delete and delete orphan. I am not using Entity Manager rather i am only using plain Hibernate + Annotations so should i define CascadeType.PERSIST or use @Cascade extension of hibernate does calling session.save(entity) and having only EJB3 style persistence annotaion of CascadeType.Persist will work without Hibernate EntityManager?...or i have to provide @Cascade with CascadeTypeas save-update?

Please help me asap.

Regards,
Shoaib Akhtar

Shoaib,

Have you looked at this? http://www.hibernate.org/hib_docs/annotations/reference/en/html/entity.html#entity-mapping-association-collections

There's an example of unidirectional one-to-many.....

As far as cascade, I believe that ALL will do what you want - ie, will save, but not delete (or delete orphan). If you want to delete orphan you have to use hibernate's own cascade annotations instead, eg:

@org.hibernate.annotations.Cascade(
{org.hibernate.annotations.CascadeType.DELETE_ORPHAN})


Hope this helps,

Hi,
Thanks for early response. I saw the documentation of hibernate and that section too and it really helped me. But onething that further confused me that in that documentation hibernate says that unidirectional one to many is very uncommon (i believe quite the opposite) and they say it is better to have join table ( really unacceptable to any DBA or even a developer too) or having bi-directional relationship (why should i do it because i dont want many to one side). So what are the real drawbacks for having only unidirectional one to many? Can anybody eleobaret it further.

Regarding the reply of second question. I believe ALL will also enable the cascaded delete ( or remove in ejb3 terms) and also i dont want delete-orphan option either. I just want save-update, merge and refresh so for this reason i want to mention it explicitly ( by not having ALL). So can u please tell me that having EJB3 style cascade behavior i.e PERSIST,MERGE,REFRESH will work without EntityManager ( i am not using that , rather using the plain Hibernate and its Session API). So clearly speaking by specifying EJB3 style annotations only does the cascading applies to session.save,session.update,session.saveOrUpdate, session.merge and session.refresh?. I am asking this because as far as i remember i read a jira issue saying that Persist will not work for Hibernate only solution. Is it true.

Regards,
Shoaib Akhtar

1.
the reasons for you to use a unidirectional one to many should lead the DBA to agree that a join table is the appropriate solution. Otherwise your reasons were wrong.
A unidirectional one to many (with join column) is not as efficient as a bidirecdtional since it requirespotentiall an extra UPDATE that could have been mutualized witht the associated entoty update

2.
Regarding cascading, CascadeType (both javx.persistence and org.hibernate.annotations) are not related to the use of HEM. If you wan to cascade saveOrUpdate, use @Cascade etc

Sorry for bringing up an old thread - but I'm struggling with the efficiency of a uni-directional one-to-many join. (Much like bennyboy here: http://forum.hibernate.org/viewtopic.php?t=969402).

I've currently seen no explanation (questions on this seem sparse), as to why Hibernate uses an insert and then an update when persisting the children in the one-to-many.

In fact, it even seems from tracing hibernates SQL generation that mutualizing the update would be perfectly possible. Again, as per Benny Boy, I see this in my sql generation:


From the ordering of the above, its clear that the parent key (generated on line 1), and used on line 6, could quite equally be part of the initial insert on line 5.

In addition, inserting a null into the foreign key field (line 5), would in many database schema's violate a database constraint.

Explanations of why appreciated!
Jason
(Hibernate 3.2, sybase 12.5)