nshupe wrote:
All of this advice pertaining to implementing .equals() and .hashCode() with respect to hibernate session, second level caching, etc. all reeks of leaky abstraction (
http://www.joelonsoftware.com/articles/ ... tions.html) that should be plugged up.
Excellent article! Agreed, this leaky abstraction needs plugging!
Quote:
What if you moved to another persistence mechanism, would all your decisions about .equals() and .hashCode() translate correctly if you had to care about hibernate when you implemented them?
The code above works independently of Hibernate, or any persistence mechanism for that matter. That said, it IS designed for Hibernate; there is probably some law of invasiveness for frameworks, and there are always trade-offs. So, this code would likely not be required in another framework.
Quote:
1. Do you really need two different instances? Could the application use the same row, and be fine? It is the same data afterall.
At the business level, my code has no concept of row, and yes, there may be multiple instances of the same object, that need to be identified properly as being the same.
Quote:
2. If not, isn't another property that could be used to identify uniqeness?
As stated above, in my context, the property must remain unchanged for the duration of the objects existence. That pretty much eliminates all "business" type properties. I can generate my own, using Java's VMID, but that has tradeoffs, primarily in performance.
Quote:
3. If not, why are you using a database generated id to indicate uniqueness at a business level? What if your entity had to be stored in two different databases, and your logic needs to look it up?
Because it is a good candidate, because it is known to be unique for a given class of objects. If it needed to be moved to another database and treated as equal, the objects implementation of Equal would need to take that into consideration. I believe the RMID approach would work; albeit with performance considerations.
Quote:
4. If people can have social security numbers, customers have account numbers, and producs have UPC codes, why can't your entity have its own code?
It can. As stated above, I would choose VMID. But, the tradeoff is performance.
Quote:
Once all these have been answered, it's usually evident that there's another approach to determine uniqueness, that there was lack of foresight when designing the database schema, or both.
Well, we are talking ORM, which also implies there could be design issues with the "Object" part of the problem, or the Bridge part of the problem.
I am definitely no expert here, but I stand aghast that no one has addressed this critical issue by summarizing the key real life issues, and the Hibernate issues and implications to consider for each approach. 109.html doesn't do it, nor does this thread, nor does the documentation.
So I ask the community at large, is there a Hibernate expert out there that can address this critical issue for us?