Pregunta

I have the following code that usually works well:

public void delete(T object)
{
  EntityManager em = getPersistence().createEntityManager();
  EntityTransaction et = em.getTransaction();
  try
  {
    et.begin();
    object = em.find(object.getClass(), object.getId());
    em.remove(object);
    em.flush();
    et.commit();
  }
  catch(Exception e)
  {
    error("Unable to delete " + object.toString() + ": there are references to it.");
  }
  finally
  {
    if (et.isActive()) et.rollback();
    em.close();
  }
}

For many of my entity classes this just works. However for two of them it does nothing, it does not throw any exceptions and it does not delete the object. The log from hibernate shows that hibernate executes a number of select queries but it doesn't even try to execute a delete.

I've already tried suggestions found in other similar questions here and here, but to no avail (well, the latter suggests @Transactional which I can't use, but I just enclosed the statements between begin() and commit() instead).

I can't seem to find what those two classes have more (or less) than the others. They use @PrimaryKeyJoinColumn just like almost all other entities I have, they have @OneToMany and @ManyToOne just like ohters. To be honest, they do have a @OneToOne(optional = false) field that references another class and that other entities do not have, but I wouldn't go through the hassle of changing that (and consequently changing the database schema) unless you tell me there could be a reason for it.

Is @OneToOne responsible? Or is my delete code bugged?

¿Fue útil?

Solución

Do you have associations in this graph that cascade a persist back to the thing being deleted? If so, the JPA spec states clearly that the provider is to cancel the delete in such a case. If this is the case, Hibernate writes out a log statement saying "un-scheduling entity deletion [...]". You could see that by enabling trace logging on the org.hibernate.event.internal.DefaultPersistEventListener logger.

If this is the situation, you'll need to clean up those associations as required by JPA specification.

Otros consejos

Replacing the cascade = CascadeType.ALL by orphanRemoval = true in the @OneToMany association gives the expected result: The child records are correctly removed without the need to delete the parent record.

Pity that error is not logged more clearly.

I got the same issue when following things gathered together.

  1. Hibernate 3.6.10.Final
  2. Parent entity with no reference to Child.
  3. Some Child entity with reference to the Parent. It is legacy code.

    class ChildEntity {
      @ManyToOne(cascade = CascadeType.ALL)
      private ParentEntity parent;
    }
    
  4. Child entity is loaded into session context and then is removed from table without JPA notification within transaction (stored procedure, native sql)

  5. Then parent can't be deleted. No deletion, no exception, just 'un-schedule deletion' message in TRACE log.

Solution: I removed cascade attribute. It was a little bit difficult for me to find which Child entity blocks Parent deletion. Also, I do not understand why Child cascade affects if I remove Parent entity.

Besides all this, once you already have Cascade and Orphan correct, in my case I found another reason why the DELETE could not be made even when all looks fine and even when the DELETE are in the log but the database don't show any change.

It also could be a transactional issue, but, in my case it was that the Key (in Oracle Database) within the delete query was a CHAR(8) data type in the Database, in that case as you can find in the Oracle documentation CHAR versus VARCHAR2 if your data is not 8 length, the rest is cover with blank, and a JPA DELETE make distinction between "0001" and "0001 ".

I write this response due I don't see something like this in all my research and someone else could get through this post and have the same problem.

Cheers.

I had the same problem with an entity that has many relations. What I did was to set to null the parent entities, to do a merge, then make a flush and clear and finally, get the entity again using find and remove. For example:

objAgreement.setParent(null);
em.merge(objAgreement);
em.flush();
em.clear();

objAgreement= em.find(Agreement.class, objAgreement.getId())
em.remove(objAgreement);
Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top