Equals et hashcode dans Hibernate

Question

Comment les de classe de modèle equals et hashcode doivent être implémentés dans Hibernate ? Quels sont les écueils courants ? Est l’implémentation par défaut assez bonne pour la plupart des cas ? Y a-t-il un sens d’utiliser des clés de l’entreprise ?

Il me semble que c’est assez difficile de l’obtenir droit au travail dans tous les cas, quelle récupération paresseux, génération d’id, proxy, etc. sont pris en compte.

Answer 1

Hibernate a une belle et longue description de quand / comment remplacer equals() / hashCode() dans la documentation

L'essentiel, c'est que vous ne devez pas vous inquiéter à ce sujet si votre entité sera le cadre d'un Set ou si vous allez être en détachement / fixation de ses instances. Ce dernier n'est pas commun. Le premier est généralement mieux traités par le biais de:

1. En fondant equals() / hashCode() sur une clé d'entreprise - par exemple, une combinaison unique de caractéristiques qui ne va pas changer au cours de l'objet (ou, au moins, une session) durée de vie.
2. Si ce qui précède est impossible, la base equals() / hashCode() sur la clé primaire SI elle est définie, et l'identité de l'objet / System.identityHashCode() sinon. L' important ici est que vous avez besoin de recharger votre Jeu après la nouvelle entité a été ajouté à cela et a persisté; sinon, vous pourriez vous retrouver avec un comportement étrange (c'est finalement ce qui entraîne des erreurs et / ou de corruption de données) parce que votre entité peut être alloué à un seau ne correspond pas à son actuel hashCode().

Answer 2

Je ne pense pas que l'on a accepté la réponse est exacte.

Pour répondre à la question initiale:

La valeur par défaut est mise en œuvre assez bon pour la plupart des cas?

La réponse est oui, dans la plupart des cas, il est.

Vous avez seulement besoin de remplacer equals() et hashcode() si l'entité doit être utilisé dans un Set (ce qui est très fréquent) ET l'entité détachée, et par la suite ré-attaché à des, sessions hibernate (ce qui est rare, de l'utilisation d'hibernate).

L'on a accepté la réponse indique que les méthodes ont besoin d'être écrasé si soit la condition est vraie.

Answer 3

L’implémentation d’equals/hashCode meilleure est lorsque vous utilisez une clé unique de l’entreprise.

La clé de l’entreprise soient cohérente dans tous les États d’entité (transitoire, attaché, détaché, enlevé), c’est pourquoi vous ne pouvez pas compter sur l’id pour l’égalité.

Il s’agit d’un article détaillé sur Hibernate equals et hashCode conseillées.

Answer 4

Lorsqu'une entité est chargé par le chargement paresseux, ce n'est pas une instance de type de base, mais est généré dynamiquement, un sous-type générés par javassist, donc un contrôle sur le même type de classe va échouer, afin de ne pas les utiliser:

if (getClass() != that.getClass()) return false;

au lieu d'utiliser:

if (!(otherObject instanceof Unit)) return false;

qui est aussi une bonne pratique, comme expliqué sur la mise en Œuvre de l'égale Java Pratiques.

pour la même raison, l'accès à directement les champs, ne peut pas travailler et retourner la valeur null au lieu de la valeur sous-jacente, n'utilisez donc pas de comparaison sur les propriétés, mais utiliser les accesseurs, car cela pourrait déclencher de charger les valeurs sous-jacentes.

Answer 5

Oui, c’est dur. Dans mon projet equals et hashCode s’appuient sur l’id de l’objet. Le problème de cette solution, c’est qu’aucun d’eux ne fonctionne si l’objet n’a pas été conservée encore, comme l’id est généré par la base de données. Dans mon cas c’est tolérable depuis dans presque tous les cas, les objets sont persistants tout de suite. Other than that, il fonctionne très bien et est facile à implémenter.