使用 EclipseLink 的 JPA 实体的 equals() 和 hashcode()
使用 JPA，我偶然发现了 equals() 和 hashcode() 的问题，特别是对于尚未持久化的新创建的实体。
我在 stackoverflow 中找到了以下答案：
这个答案讨论了 Hibernate 会话。我不使用 Hibernate（而是 EclipseLink），并且我不知道 JPA 提供程序的实现细节，例如这些“会话”。
我的问题是，就 JPA 而言，Hibernate 会话是什么？或者，更具体地说：如果我不重写 equals() 和 hashcode()，在这种情况下我会遇到两个对象代表同一实体的问题（相同的业务键（如果存在）不“相等”（这意味着 equals() 返回 false）？
使用相同的 EntityManager 实例是否足以避免出现这些问题（这意味着，“session”和“EntityManager”在这种情况下可以等效使用吗？）
注意：我没有所有表的可用业务密钥，因此无法应用在 equals() 和 hashcode() 中使用业务关键属性的解决方案。
Using JPA, I stumbled upon the problem with equals() and hashcode(), especially for newly created entities which have not yet been persisted.
I found the following answer in stackoverflow:
Should I write equals() methods in JPA entities?
This answer talks about Hibernate sessions. I do not use Hibernate (but EclipseLink), and I don't know about implementation specifics of JPA providers, such as these "sessions".
My question is, what is a Hibernate session in terms of JPA? Or, more specific: If I don't override equals() and hashcode(), in which cases would I run into the problem where two objects representing the same entity (same business key, if one exists) are not "equal" (this means equals() returns false)?
Will using the same EntityManager instance be sufficient to not getting these problems (this means, can "session" and "EntityManager" be used equivalent in this context?)
Note: I don't have a usable business key for all tables, so the solution to use business key attributes in equals() and hashcode() cannot be applied.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
EclipseLink 对 equals() 和 hashCode() 没有任何特定要求（即使在 Id 类上）。
在持久化上下文中，身份被维护，因此默认的 equals 和 hashCode 将起作用。
对于分离的对象，它们将具有不同的标识，因此 equals 不会返回 true，除非您覆盖它以使用 Id 或其他一些条件。这不会导致 EclipseLink 出现问题，但您的应用程序可能对此有依赖性。
一般来说，如果您的对象在 Sets 或 Maps 中使用，则应该正确实现 equals 和 hashCode，但 EclipseLink 始终在内部使用 Identity Maps 和 Sets，因此内部应该没有问题。
EclipseLink does not have any specific requirements for equals() and hashCode() (even on Id classes).
Within a persistence context identity is maintained, so the default equals and hashCode would function.
For detached objects they will have different identity, so equals will not return true unless you override it to use the Id or some other criteria. This will not cause an issue with EclipseLink, but your application may have dependencies on this.
In general equals and hashCode should be implemented correctly if your objects are used in Sets or Maps, but EclipseLink always uses Identity Maps and Sets internally, so should have no issues internally.
您可能有同一实体的两个分离实例，或者一个附加实例和一个分离实例，因此它们不会相等，因为默认的 equals 方法会比较物理地址。
对于没有业务密钥的实体，几乎不可能实现良好的 equals 方法。即使对于具有业务密钥的实体，如果该业务密钥是可变的，我们就注定失败。
You could have two detached instances of the same entity, or an attached one and a detached one, and they would thus not be equal, since the default equals method compares physical addresses.
It's almost impossible to implement good equals methods for entities without a business key. And even for entities with a business key, if this business key is mutable, we're doomed.