hasura/graphql-engine
1
0
Fork 0
mirror of https://github.com/hasura/graphql-engine.git synced 2024-09-11 10:46:25 +03:00
Code Issues Projects Releases Wiki Activity

docs: Clarify the impact of using an object as input to order_by.

Browse Source 
It appears this wasn't clear enough. We are now mode forceful in our recommendation to use arrays for `order_by`.

[NDAT-641]: https://hasurahq.atlassian.net/browse/NDAT-641?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/9067
GitOrigin-RevId: 643964c0bea0650751dd2605c13472c50649c650
This commit is contained in:
Samir Talwar 2023-05-08 14:23:41 +02:00 committed by hasura-bot
parent 556bb40eea
commit f4f1c9f0df
1 changed files with 11 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

17
docs/docs/resources/upgrade-hasura-v2.mdx
View File

@ -72,18 +72,23 @@ A detailed changelog with all the new features introduced in Hasura v2 is availa
i.e. `[{field1: sortOrder}, {field2: sortOrder}]` but it is also accepts a single object with multiple keys as an
input, i.e. `{field1: sortOrder, field2: sortOrder}`. In earlier versions, Hasura's query parsing logic used to
maintain the order of keys in the input object and hence the appropriate `order by` clauses with the fields in the
right order were generated .
right order were generated.
As the [GraphQL spec](http://spec.graphql.org/June2018/#sec-Input-Object-Values) mentions that input object keys are
unordered, Hasura v2.0's new and stricter query parsing logic doesn't maintain the order of keys in the input object
taking away the guarantee of the generated `order by` clauses to have the fields in the given order.
As the [GraphQL spec](http://spec.graphql.org/June2018/#sec-Input-Object-Values) specifies that input object keys are
unordered, Hasura v2.0's new and stricter query parsing logic doesn't maintain the order of keys in the input object,
removing the previous guarantee that the generated `order by` clauses specify the fields in the given order.
For example: The query `fetch_users(order_by: {age: desc, name: asc}) {id name age}` which is intended to fetch users
ordered by their age and then by their name is now not guaranteed to return results first ordered by age and then by
their name as the `order_by` input is passed as an object. To achieve the expected behavior, the following query
`fetch_users(order_by: [{age: desc}, {name: asc}]) {id name age}` should be used which uses an array to define the
their name as the `order_by` input is passed as an object. To achieve the expected behavior, the query
`fetch_users(order_by: [{age: desc}, {name: asc}]) {id name age}` should be used, which uses an array to define the
order of fields to generate the appropriate `order by` clause.
This has an effect on query operators that depend on `order_by`, most notably `distinct_on`. The `distinct_on`
operator relies on the order of `order_by`, and therefore is also impacted by this change.
To avoid confusion and potentially-unwanted behavior, you should use an array value for all `order_by` clauses.
- **Type name for computed fields' input argument has changed**
The name of the computed field input argument has changed from `<function_name>_args` to