Hi,

I have the next situation:

A---------B-----------C
1........N N........1 <---- association

class A {
private long id; <----- Primary Key
private String keyA; <----- Business key
private Set b;
....
}

class B {
private long id; <----- Primary Key
private A a;
private C c;
....
}
mapping

class C {
private long id; <----- Primary Key
private String keyC; <----- Business key
private Set b;
....
}

Mapping

Class A
<class
lazy="true"
....
<set
name="b"
lazy="true"
<one-to-many
class="B"
.....
>

Class B
<many-to-one
name="a"
outer-join="auto"
...
>
<many-to-one
name="b"
outer-join="auto"
...
>

Class C
<class
lazy="true"
....
<set
name="b"
lazy="true"
<one-to-many
class="B"
.....
>


Is it ok the next code in B class?

public boolean equals(Object other) {
if (!(other instanceof B)) {
return false;
}
B castOther = (B) other;
return new EqualsBuilder().
append(this.getA().getKeyA(),castOther.getA().getKeyA()).
append(this.getC().getKeyC(),castOther.getC().getKeyC()).
isEquals();
}

public int hashCode() {
return new HashCodeBuilder().
append(this.getA().getKeyA()).
append(this.getC().getKeyC()).
toHashCode();
}

My doubt is that when I retrieve B via HQL or Criteria, Hibernate execute aditional sql select under A and C. Why? Because the code in equals?

Thanks.

Hibernate version:

Mapping documents:

Code between sessionFactory.openSession() and session.close():

Full stack trace of any exception that occurs:

Name and version of the database you are using:

The generated SQL (show_sql=true):

Debug level Hibernate log excerpt:

Yes, key() is lazy loaded and need a DB access to be filled.
BTW you should do appendgetA(), other.getA());
And delegate the comparison to the equals implem of A, it's more elegent and less intrusive

Hi!

Even it is an old posting, I think it is still up to date. I have read the very good description about hashCode() and equals() in 'Java Persistence with Hibernate' and understand why to use the business key.

However I see two problems with it:

As described above the usage of the business key can make from an lazy association (very useful!) an non-lazy one which means additional DB calls.

The second problem is in a high concurrent system, an access like A.getB().size() can leads into an ObjectNotFoundException. Why? For filling the Set of Bs, the Set uses B.hashCode(). If this hashCode() depends on an other association with B1 and B1 is part of the business key of B, B1 must be loaded for B.hashCode(). If between the select for the Bs and the select for B1 the B instance with the associated B1 was deleted, throws A.getB().size() an an ObjectNotFoundException. An ObjectNotFoundException during access to a set ist not very intuitive.
There is a possibility to avoid this by using the primary key instead of the business key from B1 in B.hashCode(). But this means that you can only add persistent B1 to B which makes POJO unit tests impossible :-(

Bye
Kai