You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
explain why restrictions are necessary: non-null query return type is error because database might return null for non-existent id or if throws error, e.g. bookById: Book!
maybe validate returned data ourselves instead of relying on GraphQL? Could provide more specific database corruption error, e.g. if row doesn't conform to schema. But adding lots of checks would increase complexity, maintenance burden to update with every change creates friction, etc.
throw errors uniformly if concurrent change, e.g. currently returns null if concurrent change in mutation, but throws if concurrent change in query
The text was updated successfully, but these errors were encountered:
The reasons for nullability are now mentioned in the README with e34f56f
We continue returning null in a delete mutation instead of throwing a concurrent change error, because the versionstamps are given by user input and we don't want to throw for outdated user input, just like we don't throw for a non-existent id in a query.
We can think about nicer error messages by moving the return data validation in-house instead of leaving it to GraphQL later when the library is in a stable shape.
Currently, a many query returns a pageInfo even if an error is thrown in the leaf resolver and the edges are empty. This is due to the root resolvers reading the id's only, and then the leaf resolver reading any selected fields. Not clear how to solve this.
bookById: Book!
The text was updated successfully, but these errors were encountered: