CODEWITHSUNDEEP
javahibernatejpa
st-h
st-h

Reputation: 2553

Hibernate JPA: @OneToMany delete old, insert new without flush

I actually never quite understood this behavior in hibernate. I am using a @OneToMany relationship in a Entity called 'Parent', which is annotated like this:

@OneToMany(cascade = {CascadeType.ALL, CascadeType.PERSIST, CascadeType.MERGE, CascadeType.REMOVE }, orphanRemoval = true)
@JoinColumn(name = "entity_id", insertable = true, updatable = true, nullable = false)
private List<Child> children;

Now I want to do the following within one transaction:

So, basically I am just entirely replacing one of the children.

As far as I understand this problem, I should be able to do something like this: (please note that this is just some java pseudocode to illustrate the problem)

@TransactionAttribute(TransactionAttributeType.REQUIRED)
public void deleteAndAdd(Long parentId, Long childId) {
  Parent parent = entityManager.find(parentId);
  for (Iterator it = parent.children.iterator(); it.hasNext();) {
    Child child = it.next();
    if (child.id == childId) {
      it.remove();
    }
  }
  Child newChild = new Child();
  parent.children.add(newChild);
}

However, this fails in case the new Child has the same unique key values as the old one. So, basically it seems like the old child entity isn't removed properly, before the new one is persisted.

If I add a entityManager.flush() between deleting the old child and persisting the new child like this:

@TransactionAttribute(TransactionAttributeType.REQUIRED)
public void deleteAndAdd(Long parentId, Long childId) {
  Parent parent = entityManager.find(parentId);
  for (Iterator it = parent.children.iterator(); it.hasNext();) {
    Child child = it.next();
    if (child.id == childId) {
      it.remove();
    }
  }
  entityManager.flush();
  Child newChild = new Child();
  parent.children.add(newChild);
}

Everything works fine. The child is deleted before the new one is inserted, as it should.

As I don't want to asume that hibernate mixes up the order of the statements that are sent to the DB, there must be something else I am assuming about hibernate which isn't the case. Any ideas why the latter example works, while the first one doesn't?

Hibernate version is 3.5. DB is Mysql InnoDB

Upvotes: 35

Views: 24613

Answers (2)

Nikša Baldun
Nikša Baldun

Reputation: 1894

For the sake of future readers, one way to resolve this issue is to use deferred constraints. PostgreSQL and Oracle support them, maybe other RDBMS' too. Hibernate will issue all statements within a transaction, and deferral will ensure that constraints are enforced upon transaction commit only. In PostgreSQL, for example:

ALTER TABLE company
    ADD CONSTRAINT name_unique UNIQUE (name) DEFERRABLE INITIALLY DEFERRED;

It is not ideal, but it is simple and effective.

Upvotes: 37

Pace
Pace

Reputation: 43817

Hibernate doesn't know about, nor respect, all database constraints (e.g. MySQL unique constraints). It's a known issue they don't plan on addressing anytime soon.

Hibernate has a defined order for the way operations occur during a flush.

Entity deletions will always happen after inserts. The only answers I know about are to remove the constraint or add the additional flush.

EDIT: By the way, the reason for the defined order is that this is the only way to guarantee foreign key constraints (one of the constraints they DO care about) aren't violated, even if the user does something out of order.

Upvotes: 41

Related Questions