Background, from Bloch.
What the folks at Hibernate say.
This guy has another suggestion, though it won't work very well if you don't have (or can't add) an id column in a table somewhere. As well, having a public setId() method allowing any Tom, Dick or Harry to change the object's id seems to defeat the purpose of whole concept to begin with. Maybe moving setId() out of the interface into the abstract class and making it private?
More Hibernate stuff here.
3/23/08
Equals, HashCode And Hibernate
1 comment:
Pay particular attention to "When Hibernate requires you to override equals and hashCode:"
*intend to put instances of persistent classes in a Set (the recommended way to represent many-valued associations)
*intend to use reattachment of detached instances
I've successfully used hibernate on smaller projects w/o ever dealing with equals/hashcode and instead just relied on the default java reference implementations and avoided sets. There's a good chance you may need to do something with equals/hashcode (even aside from Hibernate, you might be using sets) but like all things, don't just assume you are going to need it out of the box.
That OnJava article seems pretty clever and could be slick in some situations. Using surrogate keys in the object space does have some advantages.
While we are on the rant-about-eq/hc train... Another place that using business keys for eq/hc sucks is when you have children objects who's equality depends on the parent. This means the parent has to be loaded by hibernate in order to compare it. And yeah, that object's equality might depend on it's parent, etc.
-ET
Post a Comment