@EqualsAndHashCode "não recomendado"

Oi Guilherme!

Esse alerta é do plugin JPA Buddy no Intellij: https://www.jpa-buddy.com/blog/lombok-and-jpa-what-may-go-wrong/

Ao utilizar o Lombok em entidades JPA deve-se tomar muito cuidado, pois como não "vemos" o código que está sendo gerado, podemos acabar causando efeitos colaterais indesejados. O post no blog do jpa buddy detalha os principais problemas que podem ocorrer.

Sobre o caso específico do equals/hashCode em entidades JPA, isso é uma discussão antiga com várias abordagens distintas e vantagens/desvantagens em cada uma delas. Vou listar mais dois artigos aqui para você entender melhor o problema:

• https://vladmihalcea.com/how-to-implement-equals-and-hashcode-using-the-jpa-entity-identifier
• https://web.archive.org/web/20171211235806/http://www.onjava.com/pub/a/onjava/2006/09/13/dont-let-hibernate-steal-your-identity.html (o site não existe mais, mas dá para ver pela ferramenta Wayback Machine)

Bons estudos!

Ótimo material, esse artigo no web archive em especial é muito bom!

Sendo uma artigo bem antigo tenho que perguntar, o conceito abordado de assumir a responsabilidade pela criação do ID resolvendo assim o problema de comparar objetos persistidos Vs não persistidos que representam a mesma linha no banco de dados, ainda é válido nos dias de hoje?

Valeu Rodrigo as tuas aulas são top demais, obrigado pela resposta e por todo o conhecimento!

É uma opção válida ainda, mas eu prefiro não adicionar essa responsabilidade na aplicação e nem adicionar outra coluna na tabela. Gosto da sugestão do Vlad Mihalcea, de fazer o hasCode devolver um valor fixo, pois pra mim é a solução mais simples e com menor impacto no projeto, sendo que funciona em todos os cenários de comparação de entidades.

Bons estudos!