-
30. Re: various questions
I'm really happy to see this discussion. I've been asking for this for a while now, so its good to see it might actually happen.
The thing is that, from a pure *data modelling* perspective (forget jBPM, forget usecases, forget Hibernate), all tables should have unique natural keys, as well as the surrogate key that is used for maintaining relationships. Otherwise, the table is not a proper relation. (It does not represent a set of things.)
Tom is totally wrong to suggest that this is a limitation of JPA/Hibernate (he needs to read Hibernate in Action where this is discussed carefully). You simply can't use a surrogate key for equals(), it can't possibly work, and it doesn't make sense anyway from a user point of view.
And, of course, anytime you don't have a natural key, it becomes waaay more difficult to find the data you are looking for (the surrogate key is meaningless to the user). -
31. Re: various questions
"gavin.king@jboss.com" wrote:
I'm really happy to see this discussion. I've been asking for this for a while now, so its good to see it might actually happen.
i'm squeezing it in for 3.2 cause this changes the DB schema. so you should see it shortly."gavin.king@jboss.com" wrote:
Tom is totally wrong to suggest that this is a limitation of JPA/Hibernate (he needs to read Hibernate in Action where this is discussed carefully). You simply can't use a surrogate key for equals(), it can't possibly work, and it doesn't make sense anyway from a user point of view.
in HIA, i read
"The scope of object identity",
"Outside the identity scope",
"Implementing equals() and hashCode()",
"Using database identifier equality",
"Comparing by value" and
"Using a business key"
again.
In "Implementing equals() and hashCode()" this section explains best what i want to do:
"... Nevertheless, it's possible to build a complex application with identity (default) equals as long as you exercise discipline when dealing with detached objects from different session (and keep an eye on serialization and deserialization)."
very well possible that i am totally wrong. but I still think that hibernate could provide a better helper method to support that kind of equals and hashcode, but takes the proxies into account. wouldn't such a helper method make sense ? -
32. Re: various questions
The problem is nothing to do with proxies. AFAIR, there is no problem using foo.equals(bar) with a default implementation of equals. (Even if foo and bar are proxies.)
The problem is that == is an incorrect implementation of equals, since two nonidentical objects with represent the same data (ie, the same row of the database) will not be equal. This is nothing to do with Hibernate.
"business key" equality is the correct interpretation of equals() from a data modelling perspective. It represents what the *user* thinks of as the "same objects". -
33. Re: various questions
"gavin.king@jboss.com" wrote:
The problem is nothing to do with proxies. AFAIR, there is no problem using foo.equals(bar) with a default implementation of equals. (Even if foo and bar are proxies.)
The problem is that == is an incorrect implementation of equals, since two nonidentical objects with represent the same data (ie, the same row of the database) will not be equal. This is nothing to do with Hibernate.
"business key" equality is the correct interpretation of equals() from a data modelling perspective. It represents what the *user* thinks of as the "same objects".
there is no problem with proxy1.equals(proxy2).
the problem appears when proxy1 is compared with its underlying real object. this happens when using proxies obtained from hibernate with the usage of 'this' (e.g. by passing 'this' as a parameter in another method)