Как трябва да се прилагат равенства и хешкод при използване на JPA и Hibernate

Hibernate има хубаво и дълго описание кога/как да замените equals() / hashCode() в документация

Същността на това е, че трябва да се тревожите само дали вашият обект ще бъде част от Set или ако ще отделяте/прикачвате негови екземпляри. Последното не е толкова често срещано. Първото обикновено се управлява най-добре чрез:

1. Базиране на equals() / hashCode() на бизнес ключ - напр. уникална комбинация от атрибути, която няма да се промени по време на живота на обекта (или поне сесията).
2. Ако горното е невъзможно, базирайте equals() / hashCode() на първичен ключ, АКО е зададен, и идентичност на обекта / System.identityHashCode() в противен случай. Важната част тук е, че трябва да презаредите вашия набор, след като нов обект е добавен към него и е запазен; в противен случай може да се окажете със странно поведение (в крайна сметка водещо до грешки и/или повреда на данните), тъй като вашият обект може да бъде разпределен в кофа, която не съответства на текущия му hashCode().

Не мисля, че приетият отговор е точен.

За да отговоря на първоначалния въпрос:

Изпълнението по подразбиране достатъчно добро ли е за повечето случаи?

Отговорът е да, в повечето случаи е така.

Трябва да замените equals() и hashcode() само ако обектът ще се използва в Set (което е много често) И обектът ще бъде отделен от и впоследствие отново прикрепен към сесии на хибернация (което е необичайно използване на хибернация).

Приетият отговор показва, че методите трябва да бъдат заменени, ако някое от условие е вярно.

Най-доброто изпълнение на equals и hashCode е, когато използвате уникален бизнес ключ или естествен идентификатор, като този:

@Entity
public class Company {
    @Id
    @GeneratedValue(strategy = GenerationType.AUTO)
    private Long id;
 
    @Column(unique = true, updatable = false)
    private String name;
 
    @Override
    public int hashCode() {
        HashCodeBuilder hcb = new HashCodeBuilder();
        hcb.append(name);
        return hcb.toHashCode();
    }
 
    @Override
    public boolean equals(Object obj) {
        if (this == obj) {
            return true;
        }
        if (!(obj instanceof Company)) {
            return false;
        }
        Company that = (Company) obj;
        EqualsBuilder eb = new EqualsBuilder();
        eb.append(name, that.name);
        return eb.isEquals();
    }
}

Бизнес ключът трябва да е последователен при всички преходи на състояние на обект (преходно, прикачено, отделено, премахнато), ето защо не можете да разчитате на id за равенство.

Друг вариант е да преминете към използване на UUID идентификатори, зададени от логиката на приложението. По този начин можете да използвате UUID за equals/hashCode, защото идентификаторът се присвоява преди обектът да бъде изчистен.

Можете дори да използвате идентификатора на обекта за equals и hashCode, но това изисква винаги да връщате една и съща стойност [hashCode, така че да сте сигурни, че стойността на hashCode на обекта е последователна във всички преходи на състоянието на обекта, като това:

@Entity(name = "Post")
@Table(name = "post")
public class Post implements Identifiable<Long> {
 
    @Id
    @GeneratedValue
    private Long id;
 
    private String title;
 
    public Post() {}
 
    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
 
        if (!(o instanceof Post))
            return false;
 
        Post other = (Post) o;
 
        return id != null &&
               id.equals(other.getId());
    }
 
    @Override
    public int hashCode() {
        return getClass().hashCode();
    }
  
    //Getters and setters omitted for brevity
}

Когато даден обект се зарежда чрез отложено зареждане, той не е екземпляр на основния тип, а е динамично генериран подтип, генериран от javassist, поради което проверката на същия тип клас ще бъде неуспешна, така че не използвайте:

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

вместо това използвайте:

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

което също е добра практика, както е обяснено в Имплементиране на равенства в Java Practices .

поради същата причина директният достъп до полета може да не работи и да върне null вместо основната стойност, така че не използвайте сравнение на свойствата, а използвайте гетерите, тъй като те може да задействат зареждането на основните стойности.

Да, трудно е. В моя проект, равно и hashCode разчитат на идентификатора на обекта. Проблемът на това решение е, че нито едно от тях не работи, ако обектът все още не е запазен, тъй като идентификаторът се генерира от база данни. В моя случай това е поносимо, тъй като в почти всички случаи обектите се запазват веднага. Освен това работи страхотно и е лесен за изпълнение.

В документацията на Hibernate 5.2 се казва, че може изобщо да не искате да прилагате hashCode и е равно - в зависимост от вашата ситуация.

https://docs.jboss.org/hibernate/orm/5.2/userguide/html_single/Hibernate_User_Guide.html#mapping-model-pojo-equalshashcode

Обикновено два обекта, заредени от една и съща сесия, ще бъдат равни, ако са равни в базата данни (без прилагане на hashCode и equals).

Става сложно, ако използвате две или повече сесии. В този случай равенството на два обекта зависи от реализацията на метода за равенство.

Освен това ще имате проблеми, ако вашият метод equals сравнява идентификатори, които се генерират само при запазване на обект за първи път. Те може да не са там още, когато се извика equals.

Тук има много хубава статия: https://docs.jboss.org/hibernate/stable/core.old/reference/en/html/persistent-classes-equalshashcode.html

Цитирам важен ред от статията:

Препоръчваме прилагането на equals() и hashCode() с помощта на равенство на бизнес ключове. Равенството на бизнес ключ означава, че методът equals() сравнява само свойствата, които формират бизнес ключа, ключ, който би идентифицирал нашия екземпляр в реалния свят (естествен кандидат ключ):

С прости думи

public class Cat {

...
public boolean equals(Object other) {
    //Basic test / class cast
    return this.catId==other.catId;
}

public int hashCode() {
    int result;

    return 3*this.catId; //any primenumber 
}

}

Ако се случи да отмените equals, уверете се, че изпълнявате неговите договори:-

• СИМЕТРИЯ
• ОТРАЗИТЕЛЕН
• ПРЕХОДНИ
• ПОСЛЕДОВАТЕЛЕН
• НЕ НУЛЕВ

И замени hashCode, тъй като неговият договор разчита на изпълнението на equals.

Джошуа Блок (дизайнер на рамката на колекцията) силно настоя тези правила да се спазват.

• точка 9: Винаги заменяйте hashCode, когато заменяте равно на

Има сериозен нежелан ефект, когато не спазвате тези договори. Например List#contains(Object o) може да върне грешна стойност boolean, тъй като общият договор не е изпълнен.