Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

QueryDSL datafetcher should support default arguments #867

Open
paulbakker opened this issue Jan 3, 2024 · 1 comment
Open

QueryDSL datafetcher should support default arguments #867

paulbakker opened this issue Jan 3, 2024 · 1 comment
Labels
status: blocked An issue that's blocked on an external project change
Milestone

Comments

@paulbakker
Copy link

Given a UsefulThingRepository which implements QuerydslPredicateExecutor<UsefulThing>.
The UsefulThing entity has an owner field.
When a user executes the query { usefulThing { name } } query, they should only get the items they own.
This works when owner is provided as a query argument.

However, in this case it makes sense to add the WHERE clause by default instead of relying on a query argument.
I would expect something like this work to add a default WHERE clause on the owner field.

var many = QuerydslDataFetcher.builder(repository)
                .customizer((bindings, root) -> bindings.bind(QUsefulThing.usefulThing.owner)
                        .first((path, value) -> path.eq(ssoCallerResolver.get().username).many();

Note that in this example the ssoCallerResolver.get().username is just an example of something that would give the current user form the request.

In QuerydslPredicateBuilder on line 92 there is a check on values. Since the value is not user provided, this will be empty, and it won't build a predicate.

@mp911de
Copy link
Member

mp911de commented Jan 4, 2024

QuerydslBindings are designed to be fed with request parameters and all operations following bindings.bind(…) expect request values to be consumed by the following methods.

What you're looking for is providing a default value that is either provided by a supplier function or held statically and then applied to the Querydsl binding.

I filed spring-projects/spring-data-commons#3017 to track the concern in Spring Data.

Your code shows, contrary to asking for defaulting, to override a request value. Care to clarify what the actual request is?

@rstoyanchev rstoyanchev added status: blocked An issue that's blocked on an external project change and removed status: waiting-for-triage An issue we've not yet triaged labels Jan 26, 2024
@rstoyanchev rstoyanchev added this to the 1.x Backlog milestone Jan 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: blocked An issue that's blocked on an external project change
Projects
None yet
Development

No branches or pull requests

4 participants