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

Ordering does not handle sorting by multiple fields when order is a variable #677

Closed
diesieben07 opened this issue Dec 19, 2024 · 2 comments
Labels
bug Something isn't working

Comments

@diesieben07
Copy link
Contributor

diesieben07 commented Dec 19, 2024

When sorting by multiple fields using @strawberry_django.order, the order in which the sorting is applied (i.e. "Sort by name then age" vs "Sort by age then name") is determined by the order of the fields with in the order object (this is a different issue). This does not work if the order argument is given as a variable.

Describe the Bug

Following schema is used:

@strawberry_django.order(User)
class UserOrder:
  name: auto
  birthday: auto

@strawberry_django.type(User, order=UserOrder)
class UserType:
  id: auto
  name: auto
  birthday: auto

@strawberry.type
class Query:
  users: list[UserType] = strawberry_django.field()

This query will correctly sort by birthday, then name:

query sortedUsers {
  users(order: { birthday: ASC, name: ASC }) {
    id name birthday
  }
}

This will sort by name, the birthday, it will take the order as defined in the UserOrder class, not as given by the client:

query sortedUsers($order: UserOrder) {
  users(order: $order) {
    id name birthday
  }
}

Variables:

{
  "order": {
    "birthday": "ASC",
    "name": "ASC"
  }
}

System Information

  • Operating system:
  • Strawberry version (if applicable):

Additional Context

The reason for this is this check:

if arg.name.value != ORDER_ARG or not isinstance(
arg.value, ObjectValueNode
):

In the 2nd example above, arg.value will be a VariableNode. The fix will be to handle that case as well and in that case look info info.variable_values instead of simply bailing out.

I will try to work on a PR to fix this bug soon.

Upvote & Fund

  • We're using Polar.sh so you can upvote and help fund this issue.
  • We receive the funding once the issue is completed & confirmed by you.
  • Thank you in advance for helping prioritize & fund our backlog.
Fund with Polar
@diesieben07 diesieben07 added the bug Something isn't working label Dec 19, 2024
@diesieben07
Copy link
Contributor Author

Looking into this, it seems impossible to fix for inputs provided as variables, because of this piece of code in graphql-core:
https://github.com/graphql-python/graphql-core/blob/59d478af061af9721a9a04ebc6def17c6fc30c55/src/graphql/utilities/coerce_input_value.py#L98-L119

This "coerces" every object in the variables by mapping it to the matching input type. The way it does this is that it loops through the fields of the input type, building up a new dict. The resulting dict will then always have the fields in the order that they were defined in the schema and the order given by the user is lost.
I am not sure there is a way around that without making even more horrible hacks.

To me that just means that #678 is even more imporant.

@bellini666
Copy link
Member

Going to close this as duplicated of #615 :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants