The intermediate representation was further modified so that the
operation definitions contain location information. Probably I should
introduce a data type that generalizes fields and operations, so it
contains object type, location and the selection set, so the functions
don't accept so many arguments.
The executor still doesn't give an error per argument, but a single
error per field with locations for all arguments.
If a non-null argument isn't specified, only the error location of the
field is given. If some arguments cannot be coerced, only the locations
of these arguments are given, non-null arguments are ignored. This
should still be improved, so the executor returns all errors at once.
The transformation tree is changed, so that argument map contains
locations of the arguments (but not the locations of the argument values
yet).
executeField shouldn't assume that a selection has only one field with a
given name, but it should take the first field. The underlying cause is
a wrong pattern, which (because of the laziness) is executed only if the
field has arguments.
The functions generating errors in the executor should be changed anyway
when we provide better error messages from the executor, with the error
location and response path. So public definitions of these functions are
deprecated now and they are replaced by more generic functions in the
executor code.
The old function, addErrMsg, takes only a string with an error
description, but more information is required for the execution errors:
locations and path. addErrMsg should be deprecated after the switching
to the new addError.
I found some issues with directive definitions:
- I couldn't use `on FIELD_DEFINITION`, I believe because `FIELD` was parsed
first in `executableDirectiveLocation`. I've combined both
`executableDirectiveLocation` and `typetypeSystemDirectiveLocation` into one
function which can reorder them to ensure every directive location gets a fair
chance at parsing.
Not actually to do with directives, some literals weren't being parsed
correctly.
- The GraphQL spec defines list to be `[]` or `[Value]`, but empty literal lists
weren't being parsed correctly because of using `some` instead of `many`.
- The GraphQL spec defines objects to be `{}` or `{Name: Value}`, but empty
literal objects had the same issue.
Let's try MonadThrow/MonadCatch. It looks nice at a first glance. The
monad transformer stack contains only the ReaderT, less lifts are
required. Exception subtyping is easier, the user can (and should)
define custom error types and throw them. And it is still possible to
use pure error handling, if someone doesn't like runtime exceptions or
need to run a query in a pure environment.
Fixes#42.
After the last commit there were a few places needed to be adjusted to
support subscriptions. This is done and a test case is added.
It is important to implement subscriptions now, because they require
changes to the library API, and they are a big missing part to finish
the executor. When the executor is finished, we can start to provide
more stable API without breaking everything every release. Validation
and introspection shouldn't require much changes to the API; AST would
require some changes to report good errors after the validation - this
is one thing I can think of.
Fixes#5.
This is experimental support.
The implementation is based on conduit and is boring. There is a new
resolver data constructor that should create a source event stream. The
executor receives the events, pipes them through the normal execution
and puts them into the response stream which is returned to the user.
- Tests are missing.
- The executor should check field value resolver on subscription types.
- The graphql function should probably return (Either
ResponseEventStream Response), but I'm not sure about this. It will
make the usage more complicated if no subscriptions are involved, but
with the current API implementing subscriptions is more
difficult than it should be.
