单向@OneToMany 关联未通过 JPA 中的相等性测试

Question

I have set up a unidirectional OneToMany relationship like the example in section 2.10.5.1 of the JPA 2.1 spec:

@Entity
public class Client implements Serializable {

...

    @OneToMany
    private List<ServiceOrder> activeServiceOrders;

    public void setActiveServiceOrders( List<ServiceOrder> activeServiceOrders ) {

        this.activeServiceOrders = activeServiceOrders;
    }

    public List<ServiceOrder> getActiveServiceOrders() {

        return activeServiceOrders;
    }
}

The ServiceOrder class implements hashCode and equals using its auto-generated long id. They were implemented by Eclipse.

public class ServiceOrder implements Serializable {

    @TableGenerator( name = "generator_serviceOrder", table = "SEQUENCE_TABLE", pkColumnName = "SEQ_NAME", valueColumnName = "LAST_VALUE_GEN", pkColumnValue = "SERVICE_ORDER_SEQ", allocationSize = 1, initialValue = 0 )
    @Id
    @GeneratedValue( strategy = GenerationType.TABLE, generator = "generator_serviceOrder" )
    private long id;
...
    @Override
    public boolean equals( Object obj ) {

        if ( this == obj )
            return true;
        if ( obj == null )
            return false;
        if ( getClass() != obj.getClass() )
            return false;
        ServiceOrder other = (ServiceOrder ) obj;
        if ( id != other.id )
            return false;
        return true;
    }
...
}

Tables are all auto-generated as expected. Then, when I want to establish the relationship I do:

...
Client client = entityManager.find(...);
ServiceOrder so = entityManager.find(...);
client.getActiveServiceOrders().add( so );
...

Everything is fine until now, transaction commits successfully. Problem starts when I try to remove the relationship (in another transaction, another moment):

...
Client sameClient = entityManager.find(...);
ServiceOrder sameSo = entityManager.find(...);
log.info(sameClient.getActiveServiceOrders().size()); // "1", OK
log.info(sameClient.getActiveServiceOrders().contains(so)); // "false". Why?
sameClient.getActiveServiceOrders().remove(so); // does nothing, returns false
...

I debugged and discovered that the following is failing in ServiceOrder.equals():

...
if ( getClass() != obj.getClass() ) // different probably because JPA (Hibernate) proxies one of the objects
    return false; // returns
...

I found two temporary solutions:

1. Remove ServiceOrder equals() and hashCode(); or
2. Make the relationship bidirectional (and of course update both sides every add/remove);

I don't understand this behavior. Why the difference in treatment if the relationship is uni or bi-directional? Also, if I get these entities in the context of the same transaction, how would fail the first equals test:

if ( this == obj )
    return true;

I'm using JPA 2.1 (Wildfly 8.1.0).

Best Regards and thank you in advance. Renan

Answer 1

You should override equals and hashCode but you should never use the ID for hash code unless you make the hashCode immutable and use the ID only when it's not null for equality .

Otherwise, prior to saving an Entity with the ID being null which is to be assigned during the flush time when you add a Transient entity to a collection, the moment it gets persisted and the ID is generated the equals/hashCode contract is going to broken.

Hibernate best practices suggest using a business key for object equality/hashCode.

So quoting the reference documentation:

The general contract is: if you want to store an object in a List, Map or a Set then it is a requirement that equals and hashCode are implemented so they obey the standard contract as specified in the documentation.

To avoid this problem we recommend using the "semi"-unique attributes of your persistent class to implement equals() (and hashCode()). Basically you should think of your database identifier as not having business meaning at all (remember, surrogate identifier attributes and automatically generated values are recommended anyway). The database identifier property should only be an object identifier, and basically should be used by Hibernate only. Of course, you may also use the database identifier as a convenient read-only handle, eg to build links in web applications.

Instead of using the database identifier for the equality comparison, you should use a set of properties for equals() that identify your individual objects. For example, if you have an "Item" class and it has a "name" String and "created" Date, I can use both to implement a good equals() method. No need to use the persistent identifier, the so-called "business key" is much better. It's a natural key, but this time there is nothing wrong with using it!

Answer 2

Don't override the equals and hashCode . Hibernate has its own implementation to find out the objects, and that's why you don't get the expected result. This article explains more: https://community.jboss.org/wiki/EqualsandHashCode?_sscc=t