I have various one-to-many situations where parent/child update have different requirements and I currently only use the parent object merge for all changes on parent and child.

1) update on parent without any change on its childred. Shall I set cascade="delete-orphan"?
2) update on one child. Shall I set cascade="merge"?
3) add one child. cascade="save-update"?
4) delete one child. cascade="save-update"?

Shall I have a child DAO for 2 - 4 situation instead of relying on cascade setting?

Cascade should be set in a way it defines reachability rules you want in your system. You can have a combination of cascade options or all of them. I have been in situations in which I prefer hibernate to persist everything in my object tree and in some situations I prefer to stop this cascading for performance reasons. What is your situation?



Farzad-

Thanks Farzard for your response.

That reason I would like to restudy the cascade setting is to improve performance. While the current related Hibernate configuration, including the cascade setting provide a right logic, I observe some unessential query statemenets generated by Hibernate. For example, the childrend are updated when only their parent data is updated. I try to have a right cascade setting to cut down those unessential query statements.

This can be more complicated than simply setting the right cascade option. Can you be more specific about the child update problem while updating a parent?


Farzad-

I have a few of one-to-many relationship in one class. The mapping file is something like

I only have a Hibernate DAO for Entry, but not for AddressEntity. When an Entry is updated, all its childred, addresses will be udpated with Hibernate generated SQL statements too although none of those address data is updated.

There is a few possibilities for this but my guess is that at the update point entry is a detached object therefore hibernate has no idea if its addresses have been modified. Hibernate can detect modifications if an entity exists in its first level cache. What I suggest is that you turn on caching for the collection and Entry entity and you set up hibernate to do a select before update. Merge might also have the same effect. With a second level cache the select before update has no cost but it will help hibernate find the modifications and prevent unnecessary updates. If this is not a solution for you then you will have to turn off cascades and try to persist entities manually. This will require you to decide what entities should be updated each time.

Farzad-

Since I use Hibernate with Spring, a stateless web framework. Hibernate has no way to know any data is dirty or not. I will further investigate options you mentioned. According to my note, the second_level_cache shall set to false for some reason.


Thanks for your information/helps.