QueryDslPredicateExecutor delete [DATACMNS-553]

[spring-projects-issues]

Lovro Pandžić opened DATACMNS-553 and commented

Add a delete method to QueryDslPredicateExecutor that accepts Predicate as an argument

---

Issue Links:

• DATAJPA-954 Delete by Predicate
  ("is depended on by")

[spring-projects-issues]

Lovro Pandžić commented

Any update on this?

[spring-projects-issues]

Oliver Drotbohm commented

Good idea. I'll bring this up with the team. The biggest challenge probably is to get all modules implement this addition in time for the next release. Should be doable though. Moving to Spring Data Commons where the changes need to happen

[spring-projects-issues]

Lovro Pandžić commented

Any news?

[spring-projects-issues]

member sound commented

Any updates on this? Would be nice to have a delete() method by querydsl Predicate

[spring-projects-issues]

Lovro Pandžić commented

We ended up creating our own custom repository base which you can use - https://github.com/infobip/infobip-spring-data-jpa-querydsl. It has delete, update, native query support etc

[mp911de]

@lpandzic we discussed that topic with our team. Right now, QuerydslPredicateExecutor contributes read-only methods (findBy…) to a repository. Adding a delete method would suddenly add a modifying flavor to all repositories that implement the interface thus we aren't convinced about the ratio between useful and introducing unwanted functionality.

We will revisit that topic during our efforts for Spring Data 3.0 where we want to investigate further on a read-only/read-write method split for repositories.

[Thinkenterprise]

Spring GraphQL support Querydsl and Query by Example but only for GraphQL query operations. GraphQL mutation operations which used to change data - create, update and delete - are not possible because the QuerydslPredicateExecutor does not support create, update oder delete . I think the implementation of this feature gives the Spring GraphQL Team the opportunity to support mutation operations for Querydsl and Query by Example. Currently I have to implement querysql and an additional GraphQL Controller to support mutationoperations.

[mp911de]

Both interfaces expose read-only methods. Introducing a method for deleting would introduce a notion of modification for all repositories that implement either Querydsl or Query by Example.

[Thinkenterprise]

Yes, I understand!! Reading and writing should have been taken into account right from the start, because both Query DSL and Query by Example support both, or am I wrong? Like the CrudRepository. Or is there a certain reason why change functions could not be considered from the start?

A suggestion would be to introduce a second interface QuerydslPredicate<Change>Executor just for changing as create, delete, update, then not all would be affected.

But it's just a suggestion. I don't want to demand anything, just to point out that, in my opinion, this would offer the possibility for Spring GraphQL to also support GraphQL mutations without having to implement a GraphQL Controller again. Quite similar to REST with Spring Data REST. I also have the option of calling UPDATE, POST and DELETE without having to write the REST Controller again.

[mp911de]

Part of the challenge here is that we cannot provide generic update objects. We cannot accept an entity for an update as it's not obvious what that should express. Also, we do not have generic update objects that would e.g. set individual fields, add values to an array, increment values as these operations aren't supported consistently across all store modules. So the only thing that would be left over is a delete method and there the ratio between usefulness and effort isn't in the right balance.