Open spring-projects-issues opened 10 years ago
Lovro Pandžić commented
Any update on this?
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
Lovro Pandžić commented
Any news?
member sound commented
Any updates on this? Would be nice to have a delete() method by querydsl Predicate
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
@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.
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 mutation
operations.
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.
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.
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.
Lovro Pandžić opened DATACMNS-553 and commented
Add a delete method to
QueryDslPredicateExecutor
that acceptsPredicate
as an argumentIssue Links: