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?
You can prevent that by calling the flush method on the EntityManager. After you've done that, you can remove a specific entity from the persistence context by calling the detach method or you can call the clear method to clear the persistence context completely. Query query = em.
Hibernate: delete from PRODUCT where price>? Query query = session. createQuery( "delete Category where id = :ID" );
Such target entities are considered “orphans,” and the orphanRemoval attribute can be used to specify that orphaned entities should be removed. For example, if an order has many line items and one of them is removed from the order, the removed line item is considered an orphan.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With