Hi guys,

Using Hibernate Core 3.3, Hibernate Annotations 3.4 and Hibernate EntityManager 3.4.

We have a WorkOrder entity which has a @OneToMany association with a WorkOrderDetail entity. WorkOrder is the root of this aggregate, no other entities reference WorkOrders. Throughout its life, a WorkOrder will own a variable number of WorkOrderDetails. When a WorkOrder owns no more WorkOrderDetails, it should be deleted from the database.

The way we see it, there are 2 clean options to implement this rule:
1. Creating an EntityListener for WorkOrder that would, within a @PostUpdate callback, delete the WorkOrder at the proper time
2. Creating a service for removing WorkOrderDetails from a WorkOrder, which would procede with deletion at the proper time

From what I've read, EntityListeners are not allowed to call an EntityManager in its callback methods. Option 1 is therefore ruled out.

Option 2 doesn't seem very object-oriented. Clients should be able to just call workOrder.removeWorkOrderDetail(wod) and not go through a specialized service for this.

We would like to avoid option 2, but it seems to be the only available option. How would you guys go about implementing this in a clean, object-oriented fashion?

Cheers,
Spiff

workOrder.removeWorkOrderDetail(wod) could look for zero work order details, in which case, it calls workOrderRepository.delete(this).

Thanks for your suggestion. While this would work, I see a few drawbacks to this approach:

1. My WorkOrder entity now needs to be aware of the WorkOrderRepository, which I tend to avoid so as to not mix domain logic and persistence logic
2. If the previous point cannot be avoided, WorkOrder needs to call some DI code (such as a Spring ApplicationContext) to retrieve the WorkOrderRepository, or AOP needs to be introduced
3. If the client intended to call workOrder.addWorkOrderDetail(wod) after the previous workOrder.removeWorkOrderDetail(wod), it would end up with a removed instance. Come to think of it, this disadvantage applies to my original second solution.

What's needed is a mechanism that, at the end of the use case, before the transaction commit, checks this condition and potentially deletes the WorkOrder. Clearly the @Pre/PostUpdate lifecycle callbacks would be ideal to accomplish this, and the "no call to EntityManager" restriction is all the more restrictive.