[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-5409?page=c...
]
Martin Burger commented on HHH-5409:
------------------------------------
This - IMHO - strange behavior can result in bugs which are very cumbersome to debug. For
instance, I have a history of some states. In my class History, I use an ArrayList of
instances of class State.
// states is 'life cycle object' -> cascading
@OneToMany(fetch = FetchType.LAZY, cascade = CascadeType.ALL, orphanRemoval = true)
private final List<State> states = new ArrayList<State>();
History's equals() method looks like the following one:
public final boolean equals(Object obj) {
if (this == obj) {
return true;
}
if (obj == null) {
return false;
}
if (!(obj instanceof History)) {
return false;
}
History other = (History) obj;
// we do not use fields to ensure compatibility with lazy loading
if (!Objects.equal(getStates(), other.getStates())) {
return false;
}
return true;
}
getStates() is a rather less exciting getter method.
In my unit tests, the model behaves like expected. Especially, method History.equals()
works as expected (it is well tested by equalsverifier).
However, when I test above the persistence layer, it happens that two history instances
are not equal, although they contain the same states.
How could I persist such a history properly using Hibernate?
bag and idbag should implement equals() and hashCode() the same way
as other collections
----------------------------------------------------------------------------------------
Key: HHH-5409
URL:
http://opensource.atlassian.com/projects/hibernate/browse/HHH-5409
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.3.1
Reporter: Dmitry Katsubo
bags/idbags behave in inconsistent way in comparison to set/list/map in respect to
{{equals()}} and {{hashCode()}}.
In
{{[PersistentBag.java|http://fisheye.jboss.org/browse/Hibernate/core/trunk/core/src/main/java/org/hibernate/collection/PersistentBag.java?r=HEAD#l510]}}
{{equals()}} and {{hashCode()}} methods are commented and in
{{[PersistentIdentifierBag.java|http://fisheye.jboss.org/browse/Hibernate/core/trunk/core/src/main/java/org/hibernate/collection/PersistentIdentifierBag.java?r=HEAD]}}
not present.
{{[PersistentMap.java|http://fisheye.jboss.org/browse/Hibernate/core/trunk/core/src/main/java/org/hibernate/collection/PersistentMap.java?r=HEAD#l449]}},
{{[PersistentSet.java|http://fisheye.jboss.org/browse/Hibernate/core/trunk/core/src/main/java/org/hibernate/collection/PersistentSet.java?r=HEAD#l428]}},
{{[PersistentList.java|http://fisheye.jboss.org/browse/Hibernate/core/trunk/core/src/main/java/org/hibernate/collection/PersistentList.java?r=HEAD#l484]}}
however implement {{equals()}} and {{hashCode()}} methods correctly.
The intention of this is clear: to avoid loading of the lazy collection on simple
{{equals()}} call.
* I think that it is a task for the end application to handle lazy collections as it is
aware about this situation.
* If there is a strong demand of not loading collections on {{equals()}} call for some
applications, I suggest to make this behaviour configurable via additional attribute in
XML mapping for all collections.
* The behaviour should be documented as suggested in HHH-1642. I personally spend hours
debugging before I understood why lists behave differently from bags.
Probably relative issues:
* HHH-3771 ({{equals()}} for lazy loaded objects)
* HHH-1642 ({{equals()}} for
{{[AbstractPersistentCollection.SetProxy|http://fisheye.jboss.org/browse/Hibernate/core/trunk/core/src/main/java/org/hibernate/collection/AbstractPersistentCollection.java?r=HEAD#l636]}})
--
This message is automatically generated by JIRA.
For more information on JIRA, see:
http://www.atlassian.com/software/jira