Equals for persistent objects

问题

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.

回答1:

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.

回答2:

I use the next code. It covers most cases and it could be used for all cases which I think could occur while using ORM.

public class VersionedEntity
{
        private static final long serialVersionUID=1L;
        private Long id;
        private long version;
        @Transient
        private int hashCode;
...
        public void setId(final Long id)
        {
            if(this.id != null && !this.id.equals(id))
                throw new IllegalArgumentException(this+" has an ID already, cannot change it to "+id);
            this.id = id;
        }
        @Override
        public String toString() {
            return getClass().getName()+'#'+getId();
        }

        public boolean equals(final Object o)
        {
            if (this==o) return true;
            if (!(o instanceof VersionedEntity))
                return false;
            final VersionedEntity entity=(VersionedEntity) o;
            final Long id1 = entity.getId();
            final Long id2 = getId();
            if(id1==null && id2==null)
                return super.equals(o);
            return id1 != null
                   && id2 != null
                   && id2.equals(id1);

        }

        public int hashCode()
        {
            if(hashCode == 0)
            {
                hashCode = id != null ? id.hashCode() : super.hashCode();
                if(hashCode == 0)
                    hashCode = 42;
            }
            return hashCode;
        }
}

You has to able to use collections before assigning the id. If you want create an object with a Set property which contains pack of other objects, you have to add them as elements to the Set.

来源：https://stackoverflow.com/questions/7886331/equals-for-persistent-objects