Question 1: If a parent has a lazy collection of children, children are associated with cascade="all", and I delete the parent, what will happen?

a) hibernate fetches all children, then delete them one by one
b) hibernate delete all children without fetching them

And, in case of b), what if children have children mapped with cascade="all"?

Ex:
Class A holding a lazy collection of Bs, class B holding a lazy collection of Cs.
Each collection is mapped with cascade="all".
What happen when an A is deleted?

Question 2: Is there any difference in the delete process if I was using composite-ids?
I mean, suppose that in the case above I have:

A: id->A_ID in table A

B: id->B_ID, parent ID_A in table B

C: id->A_ID and B_ID (from table B as FK) and C_ID in table C

When I delete "a" I'd like something like this:

delete from C where A_ID = a
delete from B where A_ID = a
delete from A where A_ID = a

without any select, but I think I'm asking too much...

Why nobody replies?
Is this question too complicated? Too simple? Didn't I make myself clear?

1. a.
2. no.

The lifecycle and cascade dependencies make Hibernate load objects before delete them.

Damn... isn't the other solution (delete all children without fetching them)
preferable sometimes?

Of course, it just doesn't work that easy with ORM, we have to load it. However, finding a better solution is on the TODO list for a future version.

Oh yes, I know, but Hibernate is so great that I expected some kind of miracle ;)

I think I'll go with the "persistent lifecycle callback".
Two more questions:
1) I don't like putting hibernate-code in my POJOs, so I think I will have to
extend my POJOs and implement Lifecycle. Wouldn't be better have a class-based "Interceptor" instead of a centralized one? Something like:

<class
[..]
interceptor="ThisClassInterceptor">


2) What happen if I delete through JDBC an object already loaded by Hibernate? Should I be careful in some particular occasion?

thank you

1. Have a look at the chained interceptor design pattern in the wiki area
2. Yes be careful, this is not expected by Hibernate.

1) Yes, this would solve my problem.
I would still prefer a "per-class" based solution in the configuration, though: if i get it right, with ChainedInterceptor I have to do something like:


so every time I want to add an interceptor for a particular class I have to add it to the list of interceptors, rather then simply configure a persistent lifecycle callback class in the class configuration...

2) why some (a lot, actually) of the documents in the wiki area aren't well parsed? I mean, I can't print them properly because they are too "large" (the browser doesn't wrap the lines, I don't know why).

Thank you again.

2. I've fixed Chained Interceptor. It's due to the <code/> that keep the line as it has been written. Feel free to fix others you can find :)

I concur. My Interceptor code has to inquire whether the entity implements certain interfaces, which is awkward. The Object[] arrays containing the new state, previous state, and so on, is also awkward.

With regards to the latter problem, it would be nice if Hibernate instead passed in an instance of the entity (newEntity) containing the new/previous state. Then the code could cast the entity to a specific Class and operate on it more directly... but, again, this suggests just providing an Interceptable interface that entities could implement.