Actually, my example of "moving" wasn't entirely complete, because I obviously wouldn't need orphan-delete for this enabled at all. The problem is I'd still like to have it for a simple delete of a node.

Unfortunately, this would be very, very difficult to implement.

A pity. I can imagine why this would be very difficult to implement, but it'd be fantastic if Hibernate were someday able to handle moving a child to a new parent without needing to resort to handling deletion of orphans manually. We have many examples in our code where we move a child to a new parent.

In our case, we do a lot of modification of detached entities. When the time comes to save all the changes (User hits 'Save' button), then we start a Session/Transaction and 'update' the model object to reattach it to the Session and write all the changes to disk. These updates include both removal (deletion) of objects, and transferral of objects to new parents.

Since many such changes can accumulate outside the scope of a Session, manual handling of orphan deletion would be very difficult, since we would essentially need to query the database after writing all the changes to manually find all orphaned objects. Not even sure that would be possible, since we would get exceptions if the parent were ever deleted, since the foreign key constraints of the children would be violated. Our workaround for all this is simply to clone the children which need to be moved to new parents, resulting in the original child being deleted, and a new identical child being persisted, but with a different parent. Of course, this is inelegant, inefficient and results in quite an accumulation of clones, since we also have to store 'undo' information for each movement of the child.

Anyway, probably you're sighing and thinking 'What the hell does this guy think he's doing?', but I thought it might be useful to someone if I added our use-case to this issues discussion.

Note: In HHH-1894, I have a much more simple case which is inside a transation, using non-detached objects and there, it doesn't work as well.

A pity.

I realize this issue is closed but I wanted to put in my two cents. I totally agree with Christian's argument: persistence through cascading should indeed have higher precedence than orphan-delete. As Christian says, without this feature, you must resort to complex session coding to relocate a node.

Christian's code example seems to be the most natural and transparent way to relocate a node, but it doesn't work, of course:
a.remove(b);
c.add(b);
session.flush();

The following code works but seems less natural and transparent, in my opinion:
b.setParent(c);
session.flush();
session.refresh(a);
session.refresh(c);