Soll ich schreiben equals() und hashCode() Methoden in der JPA-Entitäten?

Möchte ich überprüfen, ob Element in einer Auflistung Mitglied (@OneToMany oder @ManyToMany) von einer anderen Entität:

if (entity2.getEntities1().contains(entity1)) { }
InformationsquelleAutor j2j | 2010-12-08
  1. 116

    Nicht unbedingt. Es gibt drei Optionen:

    • nicht überschreiben - so arbeiten Sie mit Instanzen. Diese Ordnung ist in den Fällen, wenn Sie die Arbeit mit den Sammlungen, mit nur Entitäten, die befestigt sind, um die Sitzung (und somit garantiert die gleiche Instanz). Das ist (für mich) die bevorzugte Art und Weise, in vielen Fällen, denn es erfordert weniger code und weniger Rücksicht beim überschreiben

    • überschreiben hashCode() und equals() mit einem business-Taste. Das kann eine Teilmenge der Eigenschaften, die Identifizierung der Person. Zum Beispiel, für eine User ein gutes Geschäft Schlüssel sein könnte, die username oder die email. Dies ist als gute Praxis zu empfehlen.

    • überschreiben hashCode() und equals() mit dem ID-Feld nur. Das ist in Ordnung, in einigen Fällen, vor allem, wenn Sie eine manuell zugewiesene Kennung (wie eine UUID). Es ist auch in Ordnung, wenn deine Einheit wird niemals in einer Sammlung. Aber für transiente Entitäten (ohne Kennung), die in Sammlungen, es verursacht Probleme, also vorsichtig mit dieser option. Als seanizer darauf hingewiesen - sollten Sie vermeiden. In der Regel immer, es sei denn, Sie sind wirklich bewusst, was Sie tun (und vielleicht auch Dokumentation)

    Finden Sie in diesem Artikel für mehr details. Beachten Sie auch, dass equals()und hashCode() gebunden sind und umgesetzt werden sollten, die beide mit genau den gleichen Feldern.

    • nette Antwort (+1)
    • ok, ich habe dies in Entity1 und jetzt funktioniert es: public boolean equals(Object other){ if (dieser.getClass().isInstance(other)){ return diesen.id == ((UserEntity)anderen).id; } else { return false; } } public int hashCode() { return id; }
    • so dass Sie wählte die am wenigsten bevorzugte option 😉 Watch out for side-effects.
    • Jedes mal, wenn ich starten Sie eine JPA-Projekt halte ich das Ende auf diese Frage, vielen Dank für clearing meine Gedanken wieder und wieder 🙂
    • Ich empfehle die Verwendung von Lombok, es hat einen schönen @EqualsAndHashcode annotation erstellt, diese Methoden für Sie.
    InformationsquelleAutor Bozho
  2. 15

    Ja, Sie sollte!

    Wenn Sie nicht überschreiben die Standard - Java.lang.Object equals und hashCode Umsetzung: 

    @Entity(name = "Book")
public class Book implements Identifiable<Long> {

    @Id
    @GeneratedValue
    private Long id;

    private String title;

    //Getters and setters omitted for brevity
}

    den merge operation wird wieder ein anderes Objekt-Instanz und die Gleichheit Vertrag wird gebrochen werden wie erklären Sie in diesem Beitrag.

    Der beste Weg ist, verwenden Sie einen business key, wie diese:

    @Entity
public class Book implements Identifiable<Long> {

    @Id
    @GeneratedValue
    private Long id;

    private String title;

    @NaturalId
    private String isbn;

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (!(o instanceof Book)) return false;
        Book book = (Book) o;
        return Objects.equals(getIsbn(), book.getIsbn());
    }

    @Override
    public int hashCode() {
        return Objects.hash(getIsbn());
    }

    //Getters and setters omitted for brevity
}

    Können Sie auch die Bezeichner für die Gleichstellung, sondern daran, dass die hashCode-Implementierung sollte immer den gleichen Wert zurückgeben, wie in der gleichen post, die ich bereits erwähnt: 

    @Entity
public class Book implements Identifiable<Long> {

    @Id
    @GeneratedValue
    private Long id;

    private String title;

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (!(o instanceof Book)) return false;
        Book book = (Book) o;
        return Objects.equals(getId(), book.getId());
    }

    @Override
    public int hashCode() {
        return 31;
    }

    //Getters and setters omitted for brevity
}
    InformationsquelleAutor Vlad Mihalcea
  3. 13

    Ja, Sie sollte definieren, entsprechende equals() und hashcode() Methoden, aber Sie sollten lassen Sie NIEMALS die id-Teil. (Siehe dieser letzten Antwort von mir in einer ähnlichen Frage)

    • Benutzt habe ich von Zeit zu Zeit equals und hashcode überschrieben mit der id nur, und es hat alles geklappt. Stimmt, ich als usecases, und die Tatsache, dass ich nicht mit Transienten Entitäten. Also ich würde nicht sagen, dass genau das "nie":)
    • Ich hätte sage es auch nie, weil die nicht in der Lage zu vergleichen, die transiente und die angeschlossenen Einheiten ist ein no-go für mich, aber ich verstehe die Einfachheit Ihres Ansatzes (so lange wie Sie wissen, die Nachteile)
    • Das hängt davon ab, bei der Zuweisung der ids. Wenn es business-keys, die ich lieber nicht haben, andere ids an alle. Wie Sie, dass der Punkt ist strittig.
    • Ich in der Regel nicht zuweisen von IDs, die JPA-provider nicht.
    • aber ich bin damit einverstanden, business-keys als IDs ist ein nettes Konzept
    InformationsquelleAutor Sean Patrick Floyd
  5. 5

    Neigen wir dazu, uns zu lassen, IDE generieren hashCode() und equals() für uns. Seien Sie vorsichtig, wenn. Wenn Sie generieren diese Methoden für die JPA-Entitäten. Einige Versionen von equals() Prüfungen für die Klasse " identity

    //... inside equals() - wrong approach for Entities (cause of generate proxies)
if (o == null || this.getClass() != o.getClass()) {
        return false;
}
//...

    Diese brechen würden Ihre Sammlungen mit einigen JPA-Bibliotheken diese Bibliotheken erstellen, proxies, um Ihre Entitäten (Unterklassen), wie zum Beispiel MyGreatEntity_$$_javassist_7 im Ruhezustand.

    In Entitäten immer zulassen Unterklassen in equals().

    InformationsquelleAutor zbig
  6. 2

    Ist das der einzige Weg. Sie möchten möglicherweise versuchen, Pojomatic Bibliothek übernimmt die harte Arbeit für Sie.

    InformationsquelleAutor Boris Pavlović
Schreibe einen Kommentar