-
1. Re: Entity bean cascade design issue
weston.price Nov 21, 2006 10:37 AM (in response to alexg79)How about assigning the Order to another Employee. From a business perspective this would probably make the most sense right as Orders wouldn't just 'dissapear' everytime someone got canned or we would all be in trouble ;-)
-
2. Re: Entity bean cascade design issue
alexg79 Nov 21, 2006 10:41 AM (in response to alexg79)This is just the same as my solution #1, and has the same problems.
Besides, this was just an example -- I have lots of other associations like this in my project, with different semantics.
Oh, and by the way, solution #1 didn't involve removing the Order -- that'd be bad -- only severing the link to the Employee. -
3. Re: Entity bean cascade design issue
weston.price Nov 21, 2006 10:47 AM (in response to alexg79)Right which is why I mentioned assigning an 'new' employee to own the Order. I didn't mean for you to blow it away. It was a joke.
You would usually assume the Order would have to be tied to some existing employee and that employee would have to exist. Semantically I don't think it makes a lot of sense to have an Order without a customer which pretty much dictates #1, at least for this particular situation. -
4. Re: Entity bean cascade design issue
alexg79 Nov 21, 2006 11:03 AM (in response to alexg79)You would usually assume the Order would have to be tied to some existing employee and that employee would have to exist. Semantically I don't think it makes a lot of sense to have an Order without a customer which pretty much dictates #1, at least for this particular situation.
Uh...if the order has already been processed, and you reassign it to someone else, that person's sales record would be skewed. -
5. Re: Entity bean cascade design issue
weston.price Nov 21, 2006 11:11 AM (in response to alexg79)And removing the Employee for the Order, what happens to it then? How does it get recorded as a transaction? I would assume some form of reconciliation has to take place on the Order at some point. If the Employee/Order relationship is part of that reconciliation things are going to get skewed without that association as well.
If the Employee/Order relationship is not required for the business, then leaving the dangling ID might be acceptable. -
6. Re: Entity bean cascade design issue
alexg79 Nov 21, 2006 11:22 AM (in response to alexg79)And removing the Employee for the Order, what happens to it then? How does it get recorded as a transaction? I would assume some form of reconciliation has to take place on the Order at some point. If the Employee/Order relationship is part of that reconciliation things are going to get skewed without that association as well.
I don't have the faintest idea what you're talking about. Why would it need to be "recorded as a transaction"?If the Employee/Order relationship is not required for the business, then leaving the dangling ID might be acceptable.
And this is better than setting it to null how? Being able to refer to the Employee while the Order is still unprocessed is a major convenience (which is what bidirectional associations are all about).
Maybe I could use some kind of an interceptor that automates setting the property value to null? -
7. Re: Entity bean cascade design issue
weston.price Nov 21, 2006 11:37 AM (in response to alexg79)Simple Google:
http://opensource.atlassian.com/projects/hibernate/browse/ANN-250?decorator=printable
You presented three 'choices' in your original post, I was just trying to get an idea of your requirements and what it would mean to leave a dangling ID, or set the Employee relationship to NULL. I wasn't advocating any particular approach out of the three. -
8. Re: Entity bean cascade design issue
alexg79 Nov 21, 2006 11:46 AM (in response to alexg79)Simple Google:
http://opensource.atlassian.com/projects/hibernate/browse/ANN-250?decorator=printable
There we have established that Hibernate does NOT have the OnDeleteAction.SET_NULL feature. I hope it some day will, since according to the Google searches I made, a considerable number of developers would like to have this feature.
Back to the problem.
Would you consider an interceptor the best solution for this? Or just designing the application to manually sever the links prior to deleting the Employee? -
9. Re: Entity bean cascade design issue
weston.price Nov 21, 2006 11:54 AM (in response to alexg79)Personally I would go the interceptor route just to get the on/off behavior if necessary. Another nice thing about the Interceptor approach is that once the feature is implemented you can just remove it rather than having to change code and rework parts of your application.
-
10. Re: Entity bean cascade design issue
alexg79 Nov 21, 2006 12:15 PM (in response to alexg79)Hey, I just got an idea. Would this work?
@Entity public class Order { private Employee employee; ... } @Entity public class Employee { ... private List<Order> orders; ... @PreRemove public void removeRefs() { for (Order o : orders) o.setEmployee(null); } }
If this works, it'll be an elegant enough solution.
At least it'd save me the trouble of creating my own interceptors for this. -
11. Re: Entity bean cascade design issue
weston.price Nov 21, 2006 12:17 PM (in response to alexg79)Hmmm...I can't see why it wouldn't. That is quite elegant. One thing you could do, try it and also do the Interceptor. Test both...nice thing about annonations and interceptors together is that you can remove one or both.
-
12. Re: Entity bean cascade design issue
alexg79 Nov 21, 2006 12:18 PM (in response to alexg79)Hey, I just got an idea. Would this work?
@Entity public class Order { private Employee employee; ... } @Entity public class Employee { ... private List<Order> orders; ... @PreRemove public void removeRefs() { for (Order o : orders) o.setEmployee(null); } }
If this works, it'll be an elegant enough solution.
At least it'd save me the trouble of creating my own interceptors for this. -
13. Re: Entity bean cascade design issue
lcurros May 22, 2008 11:59 AM (in response to alexg79)Hi!!
I was searching info about ON DELETE SET NULL equivalent in EJB. All I found is that (probably) this is not implemented. Is this true?
The approach commented this post (with @PreRemove annotation) is correctly working. Can anybody post an example of an interceptor for this?
What are the pros and cons of each one?
Thanks in advance! -
14. Re: Entity bean cascade design issue
alexg79 May 22, 2008 12:03 PM (in response to alexg79)I was searching info about ON DELETE SET NULL equivalent in EJB. All I found is that (probably) this is not implemented. Is this true?
For some incomprehensible reason, Hibernate devs consider this functionality "bad design", even though RDMSs have supported it for a long time now. I've never heard an explanation for this, but in practice they've left us hanging. This approach was the best substitute I could think of.