Спецификация JPA, требующая конструктора без аргументов, запрещает нам писать полностью правильный хэш-код / ​​равно. Как вы справляетесь с этим?

Question

Хорошо, так что здесь [1] - отличное чтение, как действительно правильно определить хэш-код / ​​равно, а именно, в отношении иерархий объектов.Но здесь я хотел бы спросить о #pitfall 3 из этой статьи, которая показывает странное поведение, когда в изменяемых полях определен хэш-код / ​​равно, а для коллекций используется Set.Мы не можем использовать только конечные поля и параметризованный конструктор из-за спецификации JPA.Итак, каковы средства, чтобы избежать этих ошибок?Что вы используете?

Что ж, очевидно, следует избегать использования Set в сущностях JPA.Кажется, не очень приятно.Другое решение может заключаться в том, чтобы «не поддерживать» сеттеры после вызова метода equals, но это смешно и, безусловно, equals не должно иметь побочного эффекта.

Так как вы справляетесь с этим?Помимо незнания / игнорирования, что, вероятно, будет действием по умолчанию в мире Java ...

[1] https://www.artima.com/lejava/articles/equality.html

Answer 1

Если сущность отсоединена, вам нужно переопределить равные и хеш-код 1 . У каждой сущности должен быть @Id. ID является неизменным. Объекты должны реализовывать равный и хеш-код на основе идентификатора первичного ключа.

Pitfall 3 имеет дело с изменчивым объектом. Не может быть применено к сущности с неизменным идентификатором.

Руководство по реализации equals () и hashCode () с Hibernate