I read an article at

http://www.onjava.com/pub/a/onjava/2006 ... tml?page=1

and I am courious about your opinions about this.

Regards
Sergiu.

Incomplete, misleading, wrong conclusion.

Not a single time does the author mention Hibernate's persistence context, or the object identity guarantee it provides. Not once does the author mention object states, and that object identity is very much dependent on the the state an object is in. There is nothing in this article that explains how an application that never compares instances in detached state does not need a custom object equality routine.

http://www.manning.com/bauer2

We have clearly explained (several years ago now) how to handle these issues in HiA and JPwH. (Which this author does not seem to have read.) You don't need to avoid use of surrogate keys, you merely need to identify natural keys, and use them in your equals/hashCode methods. This article, IMO, did not merit publication in onjava.com.

Finally, it's surprising and amazing how few Java developers really know what object identity and equality are about.

Every OO language basically has the same concept, a built-in identity strategy (== in Java) for instance comparison, and a custom overridable construct (equals() method). Sure enough, if the built-in strategy does not satisfy the identity/equality requirements in a particular scenario, you have to write and use a custom routine.

Hibernate even _helps_ you with this when you require "one in-memory instance per database row", with it's freely extendable persistence and identity context. An article that says that "Hibernate steals your identity" can't be more wrong.

I recently ran into a problem with hashCode & equals while attempting to follow HIA's suggestions. I have a simple 'Contact' class that has first-name, last-name, and phone columns. After reading the HIA section on hashCode & equals I used the combination of all these columns as the key. Sure enough this blew up when I tried to update a detached instance (the requirements call for the user to have editing ability for all these fields). When updating the collection, it couldn't find the instance in the snapshot, so thought it was new and created an insert statement (which subsequently caused a primary-key constraint violation).

I'm certainly not blaming HIA for this; it states clearly "Instances from different sessions are no longer equal if one is modified...". But my circumstance violates the business-key equality propounded by the book. The user must be able to edit any field.

Is there an elegant solution to this?

How do users identifty your Contact instances, when they look at the screen? How can they say "this one is different than this one!" without referring to the non-visible surrogate primary key?

They can't really, at least not in some discernable way that could be modeled consistently programmatically. One can create a contact John Smith 555-555-5555 and change it to Bob Jones 444-444-4444. In reality this will probably never happen, but reasons for changing the phone number aren't hard to come by, the last name could be for marriage, and (who knows) maybe the user got the contact's first name spelled wrong or something. When I first created the key I figured the combination of all fields should at least be unique, but by using that method changing any field changes the record's identity.

So use an extended persistence context that scopes database identity across that conversation. This is a Hibernate feature.

Without Hibernate, you wouldn't even have that and would have to do some surrogate global unique key hack (like in the article).

Thanks for your replies; this is definitely an interesting subject. Can you point me to some information about using an extended persistence context like this? Like I mentioned, I have the HiA book, but not JPwH yet.

I think you have eluded to Hibernate's ability to overcome the problems outlined in the article, but I'm curious as to why you're opposed to it. It seems like a simple solution to the problem.

Like I said, the article is incomplete and misleading. Because the outlined "solution" is neither a) Hibernate related b) the best c) the primary choice.

Read JPwH.

Ok, well thanks for the info.

I ran into a problem in our shop, as relates to this. I'm sure somebody will correct me on this.

Hibernate suggests using business keys for equality, so that it can properly identify it's "identity", that is, roughly what row in the database the object represents.

A person with ID, Name, Address, Phone, nickname, whatever might be identified with a business key of just Name, and maybe Address if that isn't likely to change, if i understand the notion of a business key correctly. Fair enough.

In this way, 2 instances of this object with only a different nickname will appear to be the same object, because it's not included in the business key and equals() returns true.

I get all that, and i get why it's needed.

Problem i ran into is in our GUI/Swing portion of our application. They also use equals(). They use it to indicate a change to the entity took place, so a new view can be rendered. In their case, they need to know the above 2 instances are NOT equal, so that the correct listeners are fired and the new object replaces the old, and the nickname will be displayed.

So, we have these 2 objects. Pesistence needs these 2 objects to be equal, the GUI needs these two object to be !equal.

Caused a real rumble in our group. Both seem very reasonable.

The point i'm making is simply the choice of overriding and using .equals(). Clearly there can be many other application contexts that rely on .equals() to work in a slightly different way.

I don't have any answers to this, but since i haven't heard anybody complain about it, i'm wondering if i'm missing something real obvious or am overanalyzing it or something. Any thoughts?

FWIW, i suggested it was a problem they needed to solve - i guess they figured something out.

Hi,

i'll put my hand up and say that I am one of those java developers who don't quite get all the intricacies of equals() and hashcode().

I have read the article mentioned in this thread as well as the FAQ entry on this site. I'm still confused when I might have a problem.

I'd be grateful if someone could help me with some high-level guidelines. Here's my currrent approach:

I have designed most of my entities as using an oracle sequence (one per entity).

As soon as I have an entity thats going to be part of a Set() I stop using the above id strategy and instead switch to manually assigning a key - a class is used which wraps the oracle sequence but hibernate thinks the app is generating it.

I think I also need to implement hashcode and equals to use this new identifier?

What is wrong with this method?

Cheers

R

Hi Christian and Gavin,

As the author of the mentioned article, I'd very much like to know what the objections are to the discussed technique. Name calling aside, there wasn't really any mention of any problems with the technique.

I understand that Hibernate provides solutions to these issues, but Hibernate is very flexible and can accommodate several different techniques. Most of these solutions involve some compromise, so making different solutions available seems like a good idea. The technique I suggested has different strengths and weaknesses than the one in the documentation, and should be considered as a valid choice. Whether it's the right choice for a project depends on the requirements. This was clearly stated in the article.

Perhaps the attempt at a catchy title offended you and you began reading the article with a negative impression already. If so I apologize, my intent was certainly not the criticize the Hibernate framework. Quite to the contrary, I've be using it for some time (along with the described technique for identity) and am very pleased. My point was that Hibernate does not have to manage the assigning of database primary keys. It can, but there are other alternatives that work with Hibernate quite well (a testament to how flexible the framework is). My only suggestion is that these be mentioned in the documentation so that users have a choice.

If there is a problem with using an application-generated id for both the database primary key and for object identity, I'm very interested to hear what it is. So far this thread has not mentioned anything.

Disagreements aside, thanks for providing a excellent persistence framework. I work with Hibernate every day.

James Brundege