BREAKING CHANGE: To delete a field via the GraphQL API, the field value has to be set to `null`. Previously, setting a field value to `null` would save a null value in the database, which was not according to the [GraphQL specs](https://spec.graphql.org/June2018/#sec-Null-Value). To delete a file field use `file: null`, the previous way of using `file: { file: null }` has become obsolete.
* renamed "resetPassword" to "requestResetPassword" & created new "resetPassword" mutation
* added new route to handle resetPassword in UsersRouter.js
* updated resetPassword test to "requestResetPassword" mutation
* updated "resetPassword" mutation args description
* changed token arg description to rerun the tests
* directly using updatePassword for resetPassword
* removed handleResetPassword from UsersRouter.js file
* added test case for reset Password
* changed mutation names to "resetPassword" & "confirmResetPassword"
* changed mutation names in test also
* Excluding keys that have trailing "edges.node" on them as they will not be selectable anyway
* Updated CHANGELOG and added test case
* Forgot to change fit back to it
* Optimize query, fixes some null returns, fix stitched GraphQLUpload
* Fix authData key selection
* Prefer Iso string since other GraphQL solutions use this format
* fix tests
Co-authored-by: Antonio Davi Macedo Coelho de Castro <adavimacedo@gmail.com>
* Add test case for order option when extending the schema
* Remove fit
* upgrade to graphql-tools v5
revert #6515
Co-authored-by: Antonio Davi Macedo Coelho de Castro <adavimacedo@gmail.com>
* Allow real GraphQL Schema via ParseServer.start
* wip
* working
* tests ok
* add tests about enum/input use case
* Add async function based merge
* Better naming
* remove useless condition
* fix(GraphQL): Timeout when fetching huge collections
Currently, when not specifying a `limit` to the GraphQL find-like query, it tries to fetch the entire collection of objects from a class. However, if the class contains a huge set of objects, it is never resolved and results in timeout.
In order to solve this kind of problem, `parse-server` allows us to define a `maxLimit` parameter when initialized, which limits the maximum number of objects fetched per query; but it is not properly considered when the `limit` is undefined.
* fix: Keep same behavior as REST fetch
* Install graphql-relay
* Add relayNodeInterface to ParseGraphQLSchema
* Add support to global id
* Add support to global id in other operations
* Fix sort by glboal id
* Fix where by global id
* Introduce IdWhereInput
* Add Relay object identification tests
* Client mutation id on createFile mutation
* Client mutation id on callCloudCode mutation
* Client mutation id on signUp mutation
* Client mutation id on logIn mutation
* Client mutation id on logOut mutation
* Client mutation id on createClass mutation
* Client mutation id on updateClass mutation
* Client mutation id on deleteClass mutation
* Client mutation id on create object mutation
* Improve Viewer type
* Client mutation id on update object mutation
* Client mutation id on delete object mutation
* Introducing connections
* Fix tests
* Add pagination test
* Fix file location
* Fix postgres tests
* Add comments
* Tests to calculateSkipAndLimit
This issue was spotted when an updated field is modified in beforeSave, but the unmodified version is returned if requested by the resolver.
For example
```graphql
mutation UpdateTitle($id: ID!, $title: String!) {
updateSomeObject(id: $id, fields: { title: $title }) {
id
title
slug
}
}
```
In the above, if we modify the `title` by let's say, trimming it - the resolved `title` will not reflect this change, and instead just return the input variable. Other resolved fields that are not sent within the `fields` input are returned properly using the latest data.
