La JPA hashCode() / equals() dilemme

Lire ce très bel article sur le sujet: Ne pas Laisser Hibernate Voler Votre Identité.

La conclusion de l'article qui va comme ceci:

L'identité de l'objet est trompeusement difficile à mettre en œuvre correctement quand
les objets sont conservées dans une base de données. Cependant, les problèmes de la tige
entièrement de permettre à des objets d'exister sans une carte d'identité avant qu'ils sont
sauvé. Nous pouvons résoudre ces problèmes en prenant la responsabilité de
affectation d'Id d'objet à l'écart de mapping objet-relationnel cadres
telles que la mise en veille. Au lieu de cela, les Id d'objet peut être attribué dès que l'
l'objet est instancié. Cela rend l'identité de l'objet simple et
erreur, et réduit la quantité de code nécessaire dans le modèle de domaine.

Nous avons habituellement deux Id dans nos entités:

1. Est pour la couche de persistance seulement (alors que fournisseur de persistance et de la base de données peuvent comprendre les relations entre les objets).
2. Est pour nos besoins de l'application (equals() et hashCode() en particulier)

Prendre un coup d'oeil:

@Entity
public class User {

    @Id
    private int id;  //Persistence ID
    private UUID uuid; //Business ID

    //assuming all fields are subject to change
    //If we forbid users change their email or screenName we can use these
    //fields for business ID instead, but generally that's not the case
    private String screenName;
    private String email;

    //I don't put UUID generation in constructor for performance reasons. 
    //I call setUuid() when I create a new entity
    public User() {
    }

    //This method is only called when a brand new entity is added to 
    //persistence context - I add it as a safety net only but it might work 
    //for you. In some cases (say, when I add this entity to some set before 
    //calling em.persist()) setting a UUID might be too late. If I get a log 
    //output it means that I forgot to call setUuid() somewhere.
    @PrePersist
    public void ensureUuid() {
        if (getUuid() == null) {
            log.warn(format("User's UUID wasn't set on time. " 
                + "uuid: %s, name: %s, email: %s",
                getUuid(), getScreenName(), getEmail()));
            setUuid(UUID.randomUUID());
        }
    }

    //equals() and hashCode() rely on non-changing data only. Thus we 
    //guarantee that no matter how field values are changed we won't 
    //lose our entity in hash-based Sets.
    @Override
    public int hashCode() {
        return getUuid().hashCode();
    }

    //Note that I don't use direct field access inside my entity classes and
    //call getters instead. That's because Persistence provider (PP) might
    //want to load entity data lazily. And I don't use 
    //   this.getClass() == other.getClass() 
    //for the same reason. In order to support laziness PP might need to wrap
    //my entity object in some kind of proxy, i.e. subclassing it.
    @Override
    public boolean equals(final Object obj) {
        if (this == obj)
            return true;
        if (!(obj instanceof User))
            return false;
        return getUuid().equals(((User) obj).getUuid());
    }

    //Getters and setters follow
}

---

EDIT: pour clarifier mon point de vue concernant les appels à setUuid() méthode. Voici un scénario typique:

User user = new User();
//user.setUuid(UUID.randomUUID()); //I should have called it here
user.setName("Master Yoda");
user.setEmail("[email protected]");

jediSet.add(user); //here's bug - we forgot to set UUID and 
                   //we won't find Yoda in Jedi set

em.persist(user); //ensureUuid() was called and printed the log for me.

jediCouncilSet.add(user); //Ok, we got a UUID now

Quand je lance mes tests et voir le journal de sortie-je résoudre le problème:

User user = new User();
user.setUuid(UUID.randomUUID());

Alternativement, on peut distinguer constructeur:

@Entity
public class User {

    @Id
    private int id;  //Persistence ID
    private UUID uuid; //Business ID

    ... //fields

    //Constructor for Persistence provider to use
    public User() {
    }

    //Constructor I use when creating new entities
    public User(UUID uuid) {
        setUuid(uuid);
    }

    ... //rest of the entity.
}

Donc mon exemple pourrait ressembler à ceci:

User user = new User(UUID.randomUUID());
...
jediSet.add(user); //no bug this time

em.persist(user); //and no log output

- Je utiliser un constructeur par défaut et un setter, mais vous pouvez trouver deux constructeurs approche plus approprié pour vous.

Personnellement, j'ai déjà utilisé l'une de ces trois stratégies dans les différents projets. Je dois dire que l'option 1 est à mon avis le plus possible dans la vie réelle application. Faites l'expérience de la rupture hashCode()/equals() de la conformité conduit à de nombreuses fou bugs que vous aurez à chaque fois retrouver dans des situations où le résultat de l'égalité des changements après qu'une entité a été ajouté à une collection.

Mais il y a d'autres options (également avec leurs avantages et leurs inconvénients):

---

a) hashCode/égale basé sur un ensemble de immuable, pas null, constructeur attribué, les champs

(+) tous les trois critères sont garantis

(-) des valeurs de champ doivent être disponibles pour créer une nouvelle instance

(-) compliquent la manipulation si vous devez changer un puis

---

b) hashCode/égale basée sur la clé primaire qui est affectée par l'application (dans le constructeur) au lieu de JPA

(+) tous les trois critères sont garantis

(-) vous ne pouvez pas profiter de simple et fiable de génération d'ID de stratégies comme DB séquences

(-) compliqué si de nouvelles entités sont créées dans un environnement distribué (client/serveur) ou de l'application de serveur de cluster

---

c) hashCode/égale basé sur un UUID attribué par le constructeur de l'entité

(+) tous les trois critères sont garantis

(-) frais généraux de l'UUID de la génération

(-) peut-être un peu plus de risque que deux fois le même UUID est utilisé, en fonction de l'algorithme utilisé (peut être détecté par un index unique sur DB)

Bien que l'utilisation d'une clé d'entreprise (option 3) est le plus couramment recommandé approche (Hibernate wiki de la communauté, "Java Persistance avec Hibernate" p. 398), et c'est ce que nous utilisons principalement, il y a une Hibernate bug qui rompt pour avide de cheveux ensembles: HHH-3799. Dans ce cas, Hibernate peut ajouter une entité à un ensemble avant que ses champs sont initialisés. Je ne sais pas pourquoi ce bug n'a pas reçu plus d'attention, comme il le fait vraiment recommandé d'affaires-clés approche de la problématique.

Je pense que le coeur de la question est que equals et hashCode devrait être fondée sur l'état immuable (référence Odersky et coll.), et Hibernate entity avec Hibernate-géré clé primaire a pas tel état immuable. La clé primaire est modifiée par Hibernate lors d'un transitoire de l'objet devient persistante. La clé d'entreprise est également modifiée par Hibernate, quand il hydrate un objet dans le processus d'être initialisé.

Qui ne laisse que l'option 1, héritant de java.lang.Objet implémentations basées sur l'identité de l'objet, ou à l'aide d'une application gérée clé primaire comme suggéré par James Brundege dans "Ne pas Laisser Hibernate Voler Votre Identité" (déjà référencé par Stijn Geukens de réponse) et par Lance Arlaus dans "L'objet de la Génération: Une Meilleure Approche de mise en veille prolongée de l'Intégration".

Le plus gros problème avec l'option 1, les instances détachées ne peuvent pas être comparés avec les instances persistantes à l'aide .equals(). Mais c'est OK, le contrat de equals et hashCode laisse au développeur de décider de la signification de l'égalité pour chaque classe. Il suffit donc de laisser equals et hashCode hérite de l'Objet. Si vous avez besoin de comparer une instance détachée à une instance persistante, vous pouvez créer une nouvelle méthode explicitement à cette fin, peut-être boolean sameEntity ou boolean dbEquivalent ou boolean businessEquals.

Que d'autres gens beaucoup plus intelligents que moi l'a souligné déjà, il y a un grand nombre de stratégies. Il semble être le cas bien que la majorité de la appliqué des modèles de conception d'essayer de pirater leur chemin vers le succès. Ils limitent constructeur d'accès si pas gêner le constructeur invocations complètement spécialisés, des constructeurs et des méthodes de fabrique. En effet, il est toujours agréable avec une coupe claire de l'API. Mais si la seule raison est de faire de la equals et hashcode remplacements être compatibles avec l'application, alors je me demande si ces stratégies sont en conformité avec KISS (Keep It Simple Stupid).

Pour moi, j'aime à remplacer equals et hashcode par l'examen de l'identité. Dans ces méthodes, j'ai besoin de l'id de ne pas être null et document de ce comportement bien. Ainsi, il deviendra l'développeurs contrat de persister une nouvelle entité avant de le ranger quelque part d'autre. Une application qui ne respecte pas ce contrat serait un échec dans la minute (j'espère).

Mot d'avertissement cependant: Si votre entités sont stockées dans différentes tables et de votre fournisseur d'utiliser un auto-stratégie de génération de la clé primaire, vous obtiendrez alors dupliqué clés primaires à travers des types d'entité. Dans de tels cas, également comparer les temps d'exécution des types avec un appel à Objet#getClass() qui, bien sûr, font qu'il est impossible que deux types différents sont considérées comme égales. Qui me convient très bien pour la plupart.

Les clés d'entreprise approche ne convient pas pour nous. Nous utilisons DB généré ID, temporaire, transitoire tempId et remplacer l'égalité()/hashcode() pour résoudre le dilemme. Toutes les entités sont des descendants de l'Entité. Pros:

1. Pas de champs supplémentaires dans la DB
2. Pas de codage supplémentaire dans descendants des entités, une approche pour tous les
3. Pas de problèmes de performances (comme avec les UUID), DB Id de génération
4. Pas de problème avec Hashmaps (n'avez pas besoin de garder à l'esprit l'utilisation de l'égalité des & etc.).
5. Hashcode de la nouvelle entité n'a pas changé dans le temps, même après la persistance de

Contre:

1. Il y a peut être des problèmes avec la sérialisation et la désérialisation pas persisté entités
2. Hashcode d'enregistrement de l'entité peut changer après rechargement de DB
3. Pas d'objets persistants est toujours différent (peut-être que c'est juste?)
4. Quoi d'autre?

Coup d'oeil à notre code:

@MappedSuperclass
abstract public class Entity implements Serializable {
@Id
@GeneratedValue
@Column(nullable = false, updatable = false)
protected Long id;
@Transient
private Long tempId;
public void setId(Long id) {
this.id = id;
}
public Long getId() {
return id;
}
private void setTempId(Long tempId) {
this.tempId = tempId;
}
//Fix Id on first call from equal() or hashCode()
private Long getTempId() {
if (tempId == null)
//if we have id already, use it, else use 0
setTempId(getId() == null ? 0 : getId());
return tempId;
}
@Override
public boolean equals(Object obj) {
if (super.equals(obj))
return true;
//take proxied object into account
if (obj == null || !Hibernate.getClass(obj).equals(this.getClass()))
return false;
Entity o = (Entity) obj;
return getTempId() != 0 && o.getTempId() != 0 && getTempId().equals(o.getTempId());
}
//hash doesn't change in time
@Override
public int hashCode() {
return getTempId() == 0 ? super.hashCode() : getTempId().hashCode();
}
}

J'ai toujours utilisé l'option 1 dans le passé parce que j'étais au courant de ces discussions et pensait qu'il était mieux de ne rien faire jusqu'à ce que je savais que la bonne chose à faire. Ces systèmes sont tous encore en cours d'exécution avec succès.

Cependant, la prochaine fois je peut essayer l'option 2 - à l'aide de la base de données Id généré.

Hashcode et equals va jeter l'exception IllegalStateException si l'id n'est pas réglé.

Cela permettra d'éviter subtiles erreurs impliquant des entités non enregistrées apparaissent de façon inattendue.

Ce que les gens pensent de cette approche?

De l'OMI, vous avez 3 options pour la mise en œuvre est égal à/hashCode

• Utiliser une application générée à l'identité c'est à dire un UUID
• Mettre en œuvre sur la base d'un business clé
• Mettre en œuvre sur la base de la clé primaire

L'aide d'une application générée à l'identité est l'approche la plus simple, mais avec quelques inconvénients

• Jointures sont plus lentes lorsque vous l'utilisez comme PK parce que 128 Bits est tout simplement plus grand que 32 ou 64 Bits
• "Débogage est plus difficile" car le contrôle de vos propres yeux si certaines données sont correctes est assez dur de

Si vous pouvez travailler avec ces inconvénients, il suffit d'utiliser cette approche.

À surmonter la jointure question, on pourrait utiliser l'UUID comme naturel clé et une valeur de séquence comme clé primaire, mais peut encore fonctionner dans l'est égal à/hashCode problèmes de mise en œuvre dans la composition de l'enfant entités qui ont intégré des identifiants car vous souhaitez rejoindre basée sur la clé primaire. À l'aide de la clé naturelle de l'enfant entités id et la clé primaire pour désigner le parent est un bon compromis.

@Entity class Parent {
@Id @GeneratedValue Long id;
@NaturalId UUID uuid;
@OneToMany(mappedBy = "parent") Set<Child> children;
//equals/hashCode based on uuid
}
@Entity class Child {
@EmbeddedId ChildId id;
@ManyToOne Parent parent;
@Embeddable class ChildId {
UUID parentUuid;
UUID childUuid;
//equals/hashCode based on parentUuid and childUuid
}
//equals/hashCode based on id
}

IMO c'est le plus propre approche car elle permet d'éviter tous les inconvénients et en même temps vous fournir une valeur(UUID) que vous pouvez partager avec des systèmes externes, sans exposer le système de fonctionnement interne.

Mettre en œuvre sur la base d'un business clé si vous pouvez vous attendre à partir d'un utilisateur est une belle idée, mais est livré avec quelques inconvénients ainsi

La plupart du temps, cette clé d'entreprise sera une sorte de code qui fournit de l'utilisateur et de moins en moins souvent un composite de plusieurs attributs.

• Jointures sont plus lents à cause de rejoindre basé sur la variable de la longueur du texte est tout simplement lent. Certains SGBD peut même avoir des problèmes pour créer un index si la clé dépasse une certaine longueur.
• Dans mon expérience, les clés d'entreprise ont tendance à changer ce qui nécessitera des mises à jour en cascade les objets s'y rapportant. C'est impossible si les systèmes externes, reportez-vous à

De l'OMI, vous ne devriez pas mettre en œuvre ou de travailler avec une entreprise clé en exclusivité. C'est un complément agréable, c'est à dire aux utilisateurs de rechercher rapidement par cette activité clé, mais le système ne devrait pas compter sur elle pour l'exploitation.

Mettre en œuvre sur la base de la clé primaire a ses problèmes, mais c'est peut-être pas une grosse affaire

Si vous avez besoin d'exposer les id de système externe, utiliser l'UUID approche que j'ai suggéré. Si vous ne le faites pas, vous pouvez toujours utiliser l'UUID approche, mais vous n'avez pas à.
Le problème de l'utilisation d'un SGBD généré id est égal à/hashCode provient du fait que l'objet pourrait avoir été ajouté pour le hachage en fonction des collections avant d'attribuer l'id.

Le moyen le plus évident de contourner ce problème est tout simplement de ne pas ajouter l'objet de hachage en fonction des collections avant d'attribuer l'id. Je comprends que ce n'est pas toujours possible parce que vous pourriez déduplication avant d'attribuer l'id déjà. Pour toujours être en mesure d'utiliser le hachage en fonction des collections, il vous suffit de reconstruire les collections après l'affectation de l'id.

Vous pourriez faire quelque chose comme ceci:

@Entity class Parent {
@Id @GeneratedValue Long id;
@OneToMany(mappedBy = "parent") Set<Child> children;
//equals/hashCode based on id
}
@Entity class Child {
@EmbeddedId ChildId id;
@ManyToOne Parent parent;
@PrePersist void postPersist() {
parent.children.remove(this);
}
@PostPersist void postPersist() {
parent.children.add(this);
}
@Embeddable class ChildId {
Long parentId;
@GeneratedValue Long childId;
//equals/hashCode based on parentId and childId
}
//equals/hashCode based on id
}

Je n'ai pas testé l'approche exacte de moi-même, donc je ne sais pas comment l'évolution des collections pré - et post-persistent événements fonctionne, mais l'idée est la suivante:

• Supprimer temporairement l'objet de hachage en fonction des collections
• Persister
• Ajouter de nouveau l'objet de la table de hachage des collections

Une autre façon de résoudre ce est tout simplement de reconstruire tous vos hachage en fonction des modèles, après une mise à jour/persistent.

En fin de compte, c'est à vous. Personnellement, j'utilise la séquence de base de l'approche la plupart du temps, et de n'utiliser l'UUID approche si j'ai besoin d'exposer un identifiant à des systèmes externes.

J'ai essayé de répondre à cette question moi-même et n'a jamais été tout à fait heureux avec trouvé des solutions jusqu'à ce que j'ai lu ce post et en particulier a ATTIRÉ une. J'ai aimé la façon dont il paresseux créé UUID et stockée de façon optimale il.

Mais je voulais ajouter encore plus de flexibilité, c'est à dire paresseux créer UUID UNIQUEMENT lorsque hashCode()/equals() est accessible à l'avant première de la persistance de l'entité avec chaque solution a des avantages :

• equals() signifie "objet fait référence à la même entité logique"
• utiliser l'ID de base de données, autant que possible, car pourquoi serais-je faire le travail deux fois (en ce qui concerne les performances)
• éviter tout problème lors de l'accès à hashCode()/equals() sur les pas pourtant persisté entité et de garder le même comportement après il est en effet a persisté

J'ai vraiment aprécier des commentaires sur mon mixtes solution ci-dessous

public class MyEntity { 
@Id()
@Column(name = "ID", length = 20, nullable = false, unique = true)
@GeneratedValue(strategy = GenerationType.IDENTITY)
private Long id = null;
@Transient private UUID uuid = null;
@Column(name = "UUID_MOST", nullable = true, unique = false, updatable = false)
private Long uuidMostSignificantBits = null;
@Column(name = "UUID_LEAST", nullable = true, unique = false, updatable = false)
private Long uuidLeastSignificantBits = null;
@Override
public final int hashCode() {
return this.getUuid().hashCode();
}
@Override
public final boolean equals(Object toBeCompared) {
if(this == toBeCompared) {
return true;
}
if(toBeCompared == null) {
return false;
}
if(!this.getClass().isInstance(toBeCompared)) {
return false;
}
return this.getUuid().equals(((MyEntity)toBeCompared).getUuid());
}
public final UUID getUuid() {
//UUID already accessed on this physical object
if(this.uuid != null) {
return this.uuid;
}
//UUID one day generated on this entity before it was persisted
if(this.uuidMostSignificantBits != null) {
this.uuid = new UUID(this.uuidMostSignificantBits, this.uuidLeastSignificantBits);
//UUID never generated on this entity before it was persisted
} else if(this.getId() != null) {
this.uuid = new UUID(this.getId(), this.getId());
//UUID never accessed on this not yet persisted entity
} else {
this.setUuid(UUID.randomUUID());
}
return this.uuid; 
}
private void setUuid(UUID uuid) {
if(uuid == null) {
return;
}
//For the one hypothetical case where generated UUID could colude with UUID build from IDs
if(uuid.getMostSignificantBits() == uuid.getLeastSignificantBits()) {
throw new Exception("UUID: " + this.getUuid() + " format is only for internal use");
}
this.uuidMostSignificantBits = uuid.getMostSignificantBits();
this.uuidLeastSignificantBits = uuid.getLeastSignificantBits();
this.uuid = uuid;
}

Ci-dessous est un simple (et testé) solution pour Scala.

• Noter que cette solution ne rentre pas dans l'une des 3 catégories
  donné dans la question.

• Toutes mes Entités sont des sous-classes de la UUIDEntity j'ai donc suivi la
  don't repeat yourself (SEC) principe.

• Si besoin, la génération d'UUID peut être rendue plus précise (en utilisant plus de
  de nombres pseudo-aléatoires).

Scala Code:

import javax.persistence._
import scala.util.Random
@Entity
@Inheritance(strategy = InheritanceType.TABLE_PER_CLASS)
abstract class UUIDEntity {
@Id  @GeneratedValue(strategy = GenerationType.TABLE)
var id:java.lang.Long=null
var uuid:java.lang.Long=Random.nextLong()
override def equals(o:Any):Boolean= 
o match{
case o : UUIDEntity => o.uuid==uuid
case _ => false
}
override def hashCode() = uuid.hashCode()
}