yes, you need to explicitly remove the child. It is always wise to create helper methods that:
1. Set both sides of the relationship
2. Remove the child.
EJB3 doesn't support orphan delete.
I'm confused, Bill. Isn't this performed by using the cascade() attribute to the OneToMany annotation? What am I missing?
Yes it is confusing. only inserts and updates are cascade on a merge() if you have PERSIST and MERGE set up as a cascade. a remove cascade is only applied when you remove(). Remove an item from the colleciton does not remove it from the collection. You have to remove it from the collection and remove() the child entity. Thats just the way it works. The @ManyToOne side is the owning side of the relationship.
First of all thanks so much for your reply - I appreciate it. I will say that I struggle to understand why this would be the specified behavior. Intuitively, you would think that removing a child from the collection of the parent object should imply the desire to remove the child relationship and the relational record. Considering that it is smart enough to perform a cascade insert this is just the opposite behavior. Is this a specification definition thing or is it an implementation interpretation thing and will be different among different EJB3 implementations? It?s just interesting to me that the concept of dealing purely in the object world wouldn?t be carried all the way through when I delete an item from a collection that it wouldn?t imply a delete of the underlying record. Is there some use case that the implied behavior would not be desirable? Is this worth pushing with Sun from a specification perspective?
Yes it is weird. Yes it is non-intuitive, IMO, too. yes it is spec mandated.
Don't know why this wasn't added to spec. Sometimes things fall through the cracks or EG members can't agree on semantics.