For each entity you define there will be two query fields - one for fetching a single record by a unique field and one for fetching a list of records.
For following entity:
GraphQL schema will be similar to this (some types are omitted in the example for clarity):
If you know a field, which uniquely identifies a record, you can fetch a single record using a "get" query. If you define an entity called
Post, there will be a field
getPost with a parameter
by parameter allows to filter by any unique column (or columns in case of compound unique key). By default it is only
id, but you can specify them in model by
.unique() on the column or using
@def.Unique(...) class annotation.
This kind of query offers more possibilities like filtering using complex conditions, ordering the result or paging using limit and offset.
filter argument allows you to apply a filter on the result. On each ordinary column (which is not a relation) you can set following conditions:
It is not possible to combine multiple fields in a single object. You have to wrap using
or fields. For example, you want to select posts published in a range, then you create following condition:
You can also filter over relations (both "has one" and "has many"), for example you want to only select posts written by "John Doe" and published with a "graphql" tag
Result set can be sorted by setting an
orderBy argument. This argument can contain multiple sort fields and can also contain relations.
There is an alternative to a list queries with a similar structure - a "paginate" queries. This query aims to be Relay compatible in the future.
In addition to fields for fetching a list of records, there is a
pageInfo object with
totalCount field. Using this value you can calculate total number of pages etc.
Syntax for filtering and sorting is the same you know from "list" query. Parameters for pagination (skip, first) follows Relay specification.
Cursor based pagination is not supported.
In a single query you can traverse across all the relations of given record.
On "has many" relations, you can also set a filter, orderBy and limit with an offset.
A transaction is NOT automatically started for queries. This results in a better performance, but it may cause an inconsistency in the result.
To enable transactions, wrap queries into a