AOT repositories use `executeUpdate` for derived `@Modifying` queries

[ditogam]

Incorrect AOT code generation for derived delete queries (simple reproducible example)

I created a minimal reproducible project that demonstrates incorrect AOT code generation for some Spring Data JPA derived queries.

Repository:
https://github.com/ditogam/TestJPAAOT

Build command:
./gradlew nativeCompile

This project shows that some derived query methods are generated correctly, while others behave differently under AOT compared to normal JVM execution.

Note: The issue with Set return types is already tracked here:
#4094

This report focuses only on the delete query AOT inconsistencies.

---

Repository under test

public interface UserRepository extends JpaRepository<UserEntity, Long> {

    // Correctly generated by AOT
    void deleteByEmail(String email);

    // Incorrect AOT generation
    @Modifying
    void deleteByEmailAndIdIsNotNull(String email);

    // Known Set<T> issue (#4094)
    Set<Long> findDistinctUserIdsByStreetLike(String street);
}

Behavior comparison

deleteByEmail(String email) is generated correctly by AOT and behaves the same as non-AOT runtime.

deleteByEmailAndIdIsNotNull(String email) is generated incorrectly.
In normal JVM mode, Spring Data executes this derived delete query correctly.
Under AOT, the generated UserRepositoryImpl__AotRepository does not follow the same semantics.
AOT seems to treat this as a bulk update/delete solely because @Modifying is present, even though this is a derived delete method that should follow the standard delete semantics.

The result is that the AOT-generated implementation behaves differently from normal Spring Data behavior.

findDistinctUserIdsByStreetLike(String street) fails due to the known Set-return bug and is not part of this report. It is only included to show the complete generated file.

---

Expected behavior

AOT-generated repositories should behave exactly the same as the non-AOT runtime repositories.

Specifically:

1. Derived delete queries with @Modifying should still be generated as proper delete operations.
2. A condition like AndIdIsNotNull should not change the AOT query generation logic.
3. AOT should not rewrite or reinterpret derived delete queries differently than standard Spring Data JPA.

---

Actual behavior

deleteByEmail is correct.

deleteByEmailAndIdIsNotNull is generated incorrectly and does not match runtime behavior.
The generated AOT code does not follow the standard delete derivation rules.

findDistinctUserIdsByStreetLike fails for a known reason (#4094).

Everything works correctly when AOT is disabled.

---

How to reproduce

1. Clone:
   https://github.com/ditogam/TestJPAAOT

2. Run:
   ./gradlew nativeCompile

3. Inspect generated code:
   build/generated/aotSources/.../UserRepositoryImpl__AotRepository.java
   or the compiled class.

4. Run:
   ./gradlew clean test

5. Run will fail
   ./gradlew clean nativeTest

JUnit Jupiter:UserRepositoryTest:shouldFindDistinctUserIdsByStreetLike()
   MethodSource [className = 'org.example.testjpaaot.jpa.UserRepositoryTest', methodName = 'shouldFindDistinctUserIdsByStreetLike', methodParameterTypes = '']
   => java.lang.ClassCastException: java.util.ArrayList cannot be cast to java.util.Set

 JUnit Jupiter:UserRepositoryTest:shouldDeleteByEmailAndIdIsNotNull()
   MethodSource [className = 'org.example.testjpaaot.jpa.UserRepositoryTest', methodName = 'shouldDeleteByEmailAndIdIsNotNull', methodParameterTypes = '']
   => org.springframework.dao.InvalidDataAccessApiUsageException: Query executed via 'executeUpdate()' must be an 'insert', 'update', or 'delete' statement [SELECT u FROM UserEntity u WHERE u.email = :email AND u.i

---

Request

Please confirm:

1. Whether incorrect generation of derived delete queries with @Modifying is a known issue.
2. Whether this is a bug in the AOT repository generator.
3. Whether any workaround exists until the AOT generator is fixed.

Thank you.

[mp911de]

I've updated your report summary to reflect the actual concern discussed here.

Thanks for providing the reproducer. Were you able to verify that the Set conversion fix works for you when using 4.0.1-SNAPSHOT?

As a general note, please avoid submitting AI-generated content to the issue tracker. Such reports tend to be verbose and repetitive, which makes it unnecessarily time-consuming to distill relevant details. For future issues,
if you want us to spend time helping you, please spend time first on a clear and concise description.

Also, we've fixed the behavioral difference between AOT and reflective delete methods; Derived deletes use an entity selection regardless whether a @Modifying annotation is present.