This is certainly not the recommended approach and I'd be interested where you found such a statement. You should implement euqals/hashcode if you'd like to use your domain objects outside of a session (mix them in a Set, probably). You have to implement equals/hashcode if you use composite keys.

Please read this page carefully:

http://www.hibernate.org/109.html

The latest Hibernate tools release does NOT generate equals/hashCode by default:

http://sourceforge.net/project/shownotes.php?release_id=230049

Christian, I think you missed the point of eepstein's question. If you are careful about re-associating your objects at the start of a new session, you should be able to get away with not overriding equals/hashCode. Shouldn't you?

Cheers!
Rob

I don't think that the recommendation to "Seperating object id and business key" as shown on http://www.hibernate.org/109.html will work for us very often. We do have things that at first blush seem to qualify. We have components that have names which are unique within their parent's subcomponents. So we could do an equality check on the combination of name and parent (or parent_id) to avoid a chain of fetches. But the problem is that name is updatable according to our use cases. So we have the old problem of the hashCode changing and that's a fundamental no-no for objects... esp. one's that live in collections.

All this for me boils down to just on option: GUIDs (or UUIDs since we're in Java). Create a private field that hold a UUID and use it for eq/hc and make it immutable. Proxies still have the inflation issue but all other problems go away. 'course I need a trigger in the DB to set a UUID for rows that are Inserted via SQL (one of our use cases) but otherwise this seems to be the most straight-forward and performant approach.

(The trick of saving when hashCode() is first called looked nifty, but I'm concerned about performance.)

So, after the ramble, is there an authoritative suggestion on what to do about this issue and its implications. I didn't find 109.html very satisfying.

Actually, its really trivial.

First: Hibernate doesn't change anything about equals/hashcode. It's just that Hibernate makes you think about it maybe for the first time!

Second: Implement equals/hashcode like you would without Hibernate. You add two objects to a Set and you know that equals() will be called. Hibernate doesn't change any of the semantics, and, because it simply can't, doesn't provide any help with that. Are the two objects "the same" from your point of view or not? Hibernate doesn't know!

No Hibernate trick will do the work for you. It's transparent. The problem is not anywhere in Hibernate or close to Hibernate.

Don't get me wrong:

You have to implement equals/hashcode for composite identifier classes/components. Thats just a Hibernate requirement, but its an exceptional case.

Also, after deciding how you solve the problem of identity/equality without thinking about Hibernate, you may find that there are some problems with the implementation, like the accessing of a lazy property/proxy that would kill performance. This is a secondary issue. So, in a way, you are more restricted in your choice of properties for business keys/equality. Thats the tradeoff of persistent objects, it never is fully transparent.

But, for gods sake, please: Stop blaming Hibernate, stop blaming us, stop being mad at everyone else, just because you have a problem with Java identity/equality for the first time. I know that it sucks bad. Even without Hibernate.

Ah, Christian, Christian, Christian. If you can really read this whole thread and still think that the problem is not at all related to Hibernate, then I don't think there's anything more that can be said.

There are definitely more potential semantics for mapping object equality to relational equality than 109.html describes, and it is related to Hibernate insofar as Hibernate is responsible for relating object identity to relational identity.

But you don't have to agree :-)

Cheers!
Rob

Could someone elaborate on this:



from http://www.hibernate.org/109.html I don't quite see the "why" of it.

Oops, missed your second reply.

I don't know that anyone here is blaming Hibernate. I LOVE Hibernate! It makes my life enormously better on a daily basis, and it is the foundation of our whole next-generation product.

It's just that Hibernate, as you say, provides a framework for confronting these issues more intensively than many of us yet have. And yes, much of the thrashing in this thread is due to trying to satisfice both the primary goals of basic identity semantics, and the secondary goals of proxy performance et al. It's in that trying-to-solve-all-problems-at-once that the issues arise.

But for the record: IT'S DEFINITELY NOT HIBERNATE'S FAULT!!!!!

:-D
Cheers!
Rob

The reason is that Hibernate will be constructing instances of these composite id objects as it reads back the containing objects from the database, and it will then be updating its session cache, which is basically a big HashMap of the objects loaded in the session. It updates the session cache by comparing the identifiers of the loaded objects to the identifiers of the objects in the cache, to determine when objects should be newly added versus when the cache objects should be reused in the load results.

So if the composite id objects don't define state-based equality, then they will NEVER be equal to the existing objects in the session cache, which is definitely not what you want!

Cheers,
Rob

Yeah, that's why this thread is so short.

[quote]First: Hibernate doesn't change anything about equals/hashcode.[\quote]

That statement is false not only for Hibernate but for all O/R mappings. One of the key things an O/R tool needs to do is bridge 2 distinct notions of equality. I can choose to define object equality all sort of ways. But tuple equality has a fixed definition.

The problem boils down to not having an Id before save. WebObject's EOF (which goes back to about 1993/4) handled this by using temporary Ids until an object was saved. This amounts to the GUID approach. Or pre-fetching keys. I could see a version of HiLo that prefetches N keys and then doles them out sequentially. This would probably work too. The point is you need some meaning of equals that is consistent between the objects and the DB. The best way seems to me to get the Id at creation. Performance issue preclude a full DB r/t so then we come to things like caching keys or using a GUID/UUID.

Yes?

eepstein: Yes, you could potentially set up some kind of persistent-ID-assignment in your object constructors. That was one of the very first suggestions in this whole thread, in fact: using assigned identity generation. Then your objects would be "born" with their persistent identity.

This requires some tricky GUID generation, implies fairly heavyweight UUIDs, and is unnecessary for many use cases of Hibernate. (We have no need for it in our application, for instance.) But if it's the semantics you consider the cleanest, and if you can handle the performance overhead, then go for it! Hibernate will support it just fine :-)

Cheers!
Rob

Guys, did you think about simply _not_ mixing objects outside of sessions? And stop trying to tell me what ORM is about.

I don't blame. I'm just not sure I agree with your claims. I don't know what about the writing here gives the impression that I'm mad. I'm not.

I see this as an issue with trade-offs (due to persistence be it Hibernate or another scheme) and I'm trying to work through which might be the best options given some strong constraints. Looking at the summary table on 109.html led me to believe that only "business-key" based eq/hc works for all 4 use cases. From that I notice that for us there isn't always such a field (we've got domain objects not value objects). So the next step was to say: let's add a field. Well, what types of values should it have? UUID seems fine. Heck any locally unique value is fine. Indeed the pk from the table would be fine. So then comes the choice: change all our PKs to UUID.hex .... or add UUID (or similar) to all our objects?

It's true I thought I could ignore this, but lots of bugs have cropped up with Collections and uniqueness and ordering (List) and concurrency and ... I'm wondering who's tried what that works.

CHristian, is that correct: assuming we do a lock() call to reassociate transient objects before we start loading objects into the new session? 109.html simply says

equal to same object from other session No

in the "no eq/hC at all" column. Are there caveats?

You mean across sessions? How can I support concurrency?