Jparepository Not supported for DML operations

Steering clear of transactional semantics

Don’t forget to annotate service methods, not repository interfaces, with @Transactional. This ensures transactional integrity managed by the service layer, upholding a neat segregation of responsibility within your application. Here's an example:

public interface MyService {
    void deleteSomeData(String value);
}

@Service
public class MyServiceImpl implements MyService {
    
    private final MyRepository myRepository;

    @Autowired
    public MyServiceImpl(MyRepository myRepository) {
        this.myRepository = myRepository;
    }

    @Override
    @Transactional
    public void deleteSomeData(String value) {
        myRepository.performDeletion(value); // BOOM! Data vanishes just like my social life during coding weekends!
    }
}


EntityManager vs JpaRepository: The eternal debate

If you're looking for extra control for more complex DML operations, EntityManager lends a more flexible hand than JpaRepository. For instance, when confronted with an overly intricate delete operation, opt for entityManager.createQuery().executeUpdate(). This technique offers granular transaction and query execution control. (One ring to rule them all, anyone? 😉)

Pitfalls to watch out for

• Never ever use @Transactional on repository interface methods. Its rightful place is at service layer classes only.
• Be careful with the import of @Modifying, @Transactional, and @Query annotations.
• Be mindful of transaction propagation. Operations inside a @Transactional method should be treated as a unit of work, just like Avengers assembling!

Dynamic conditions, dynamic responses

With unforeseen dynamics at play, there might be situations where you need to eliminate entities based on fluctuating conditions. Enter Criteria API or Querydsl that offer more advanced options. These tools facilitate a programmatic way to create SQL queries dynamically, serving especially useful when finalizing filtering ops based on multifarious criteria known only at runtime.

Preparing for common errors

Watch out for common slip-ups like:

• Misplacing JPQL query indexing with ?1, ?2, and so on, leading to some pretty bizarre behavior.
• Missing out on the @Param annotation on method parameters causing parameter-binding woes.
• Overlooking @Modifying necessity for delete/update operations, leading to unsupported operation errors. Just like forgetting your mask these days!