CODEWITHSUNDEEP
spring-boothibernatespring-data-jpaspring-data
user1283068
user1283068

Reputation: 1804

Spring Data problem - derived delete doesn't work

I have a spring boot application (based off spring-boot-starter-data-jpa. I have an absolute minimum of configuration going on, and only a single table and entity.

I'm using CrudRepository<Long, MyEntity> with a couple of findBy methods which all work. And I have a derived deleteBy method - which doesn't work. The signature is simply:

public interface MyEntityRepository<Long, MyEntity> extends CrudRespository<> {
    Long deleteBySystemId(String systemId);
    // findBy methods left out
}

The entity is simple, too:

@Entity @Table(name="MyEntityTable")
public class MyEntity {
    @Id
    @GeneratedValue(strategy=GenerationType.IDENTITY)
    @Column(name="MyEntityPID")
    private Long MyEntityPID;

    @Column(name="SystemId")
    private String systemId;

    @Column(name="PersonIdentifier")
    private String personIdentifier;

   // Getters and setters here, also hashCode & equals.
}

The reason the deleteBy method isn't working is because it seems to only issue a "select" statement to the database, which selects all the MyEntity rows which has a SystemId with the value I specify. Using my mysql global log I have captured the actual, physical sql and issued it manually on the database, and verified that it returns a large number of rows.

So Spring, or rather Hibernate, is trying to select the rows it has to delete, but it never actually issues a DELETE FROM statement.

According to a note on Baeldung this select statement is normal, in the sense that Hibernate will first select all rows that it intends to delete, then issue delete statements for each of them.

Does anyone know why this derived deleteBy method would not be working? I have @TransactionManagementEnabled on my @Configuration, and the method calling is @Transactional. The mysql log shows that spring sets autocommit=0 so it seems like transactions are properly enabled.

I have worked around this issue by manually annotating the derived delete method this way:

public interface MyEntityRepository<Long, MyEntity> extends CrudRespository<> {
    @Modifying
    @Query("DELETE FROM MyEntity m where m.systemId=:systemId")
    Long deleteBySystemId(@Param("systemId") String systemId);
    // findBy methods left out
}

This works. Including transactions. But this just shouldn't have to be, I shouldn't need to add that Query annotation.

Here is a person who has the exact same problem as I do. However the Spring developers were quick to wash their hands and write it off as a Hibernate problem so no solution or explanation to be found there.

Oh, for reference I'm using Spring Boot 2.2.9.

Upvotes: 1

Views: 1856

Answers (1)

Oliver Drotbohm
Oliver Drotbohm

Reputation: 83051

tl;dr

It's all in the reference documentation. That's the way JPA works. (Me rubbing hands washing.)

Details

The two methods do two different things: Long deleteBySystemId(String systemId); loads the entity by the given constraints and ends up issuing EntityManager.delete(…) which the persistence provider is about to delay until transaction commits. I.e. code following that call is not guaranteed that the changes have already been synced to the database. That in turn is due to JPA allowing its implementations to actually do just that. Unfortunately that's nothing Spring Data can fix on top of that. (More rubbing, more washing, plus a bit of soap.)

The reference documentation justifies that behavior with the need for the EntityManager (again a JPA abstraction, not something Spring Data has anything to do with) to trigger lifecycle events like @PreDelete etc. which users expect to fire.

The second method declaring a modifying query manually is declaring a query to be executed in the database, which means that entity lifecycles do not fire as the entities do not get materialized upfront.

However the Spring developers were quick to wash their hands and write it off as a Hibernate problem so no solution or explanation to be found there.

There's detailed explanation why it works the way it works in the comments to the ticket. There are solutions provided even. Workarounds and suggestions to bring this up with the part of the stack that has control over this behavior. (Shuts faucet, reaches for a towel.)

Upvotes: 2

Related Questions