等于持久对象 [英] Equals for persistent objects

问题描述

实现equals（）（和hashCode（），我会谈论关于equals（））的持久对象与数据库管理的id有一个众所周知的问题。
新对象没有存储在数据库中，因此没有数据库标识，因此其id字段为空（如果是原始类型，则为0）。

如果equals等于id，它会认为所有新对象都是相等的，一旦它得到id，哈希代码就会改变，所以如果它已经在哈希敏感集合中，它就不会被发现。

一种解决方案是使用商业密钥，但有时候除了代理id以外的所有内容都是可变的。
另一个解决方案是在创建对象时生成（另外一个，或者将它用作databes id）替代id。

我没见过的方法是在等于id时使用id，当id为null时，使equals（和hashCode（））失败（抛出IllegalStateException）。 （并记录这种行为）
这样它仍然不能在哈希集合中，但它不能意外地放在那里。如果没有id，把它放在集合中，可以使用一些包装器。
好​​/坏主意？它有隐藏的问题吗？

正如kan指出的那样，如果子对象应该放在Set属性中并且与父对象保持一致，那么在它们之前无法将对象放入Set坚持是很大的问题（并且TreeSet不起作用，因为它使用equals（），即使它不使用hashCode（））。
我主要使用子实体的列表，所以它不需要显式化，但它肯定是问题。

解决方案

我总是使用自动生成的ID并从未遇到过问题。你可以在实例化时强制一个对象，也可以使用你的服务层/工厂持久化。

我认为任何其他领域（构成一个biz键）比在散列表中使用非持久对象更有可能，然后在同一时间持续导致查找失败。

这个问题，imho，有些过度分析。自动生成的ID通常是我想要为平等做的唯一测试，在许多情况下没有其他意义。我采取的方法是，如果正在使用/比较非持久对象，问题出现在业务逻辑中，而不是基础的equals / hashcode方法中。

要特别回答非法状态的概念，当对象不平等和/或没有被持续时引发异常似乎相当戏剧性。

There is well known problem with implementing equals() (and hashCode(), i will speak about equals() only) for persistance object with database managed id. New object is not stored in database, therefore does not have database identity, therefore its "id" field is null (or 0 if it is primitive type).

If equals look at id, it will consider all new objects equal, and once it gets id, hash code change so if it already was in hash sensitive collection, it will not be found.

One solution is using business key, but sometimes everything except surrogate id is mutable. Another solution is to generate (one more, or use it as databes id too) surrogate id when object is created.

Approach I haven't seen mentioned is, use id in equals and make equals (and hashCode()) fail (throw IllegalStateException) when id is null. (and document this behavior) This way it still can't be in hash collections, but it cannot be accidentaly put there. And for puting it in collections when without id, some wrapper can be used. Is it good/bad idea? Does it have hiddent problems?

As kan pointed out, if child objects should be put in Set property and persisted with their parent, inability to put objects in Set before they are persisted is big problem (and TreeSet does not help, because it uses equals(), even if it does not use hashCode()). I mostly use list for child entities, so it does not need to manifest, but it definitely is problem.

解决方案

I always use the auto-generated id and have never had a problem. You could enforce an object when instantiated to also be persisted using your service layer/factory.

I think the likelihood of any other field (composing a biz key) changing is much more probable than using a non-persisted object in a hashmap and then persisting at the same time causing the look up to fail.

This problem, imho, is somewhat over-analysed. The auto-generated id is often the only test I want to do for equality, nothing else makes sense in a lot of cases. I take the approach that if a non-persisted object is being used/compared the problem is in the business logic and not the underlying equals/hashcode methods

To specifically answer the illegalstateexception idea, throwing an exception when objects are not equal and/or have not been persisted seems rather dramatic.

这篇关于等于持久对象的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！