Easily restore your project to a previous version with our new Instant One-click Backup Recovery
Hygraph
Docs

Filtering

#Overview

Hygraph automatically creates filters for types you add to your content models. These filters can be applied to a single, or multiple entries, and nested object fields.

The best place to explore all available filters is by using the API Playground.

#Using filters

To filter content entries, simply pass the where argument to the query, followed by any of the filter types for the fields on your model.

For example, a Post model will have the where input types PostWhereInput and PostWhereUniqueInput on the posts, and postsConnection query types. These types contain filters specific to that content type.

#Filter types

#ID

Entries can be filtered by id.

MatchesTypeBehavior
idIDEqual to
id_notIDNot this (null excepted)
id_in[ID!]One of
id_not_in[ID!]Not one of
id_starts_withIDStarts with
id_not_starts_withIDDoes not start with
id_ends_withIDEnds with
id_not_ends_withIDDoes not end with
id_containsIDContains
id_not_containsIDDoes not contain

#String

All String fields can be filtered using:

MatchesTypeBehavior
[fieldName]_notStringNot this (null excepted)
[fieldName]_in[String]One of
[fieldName]_not_in[String]Not one of
[fieldName]_starts_withStringStarts with string
[fieldName]_not_starts_withStringDoesn't start with string
[fieldName]_ends_withStringEnds with string
[fieldName]_not_ends_withStringDoesn't end with string
[fieldName]_containsStringIncludes string
[fieldName]_not_containsStringDoes not include string

#Integer

All Integer fields can be filtered using:

MatchesTypeBehavior
[fieldName]_notIntNot this (null excepted)
[fieldName]_in[Int]One of
[fieldName]_not_in[Int]Not one of
[fieldName]_ltIntLess than
[fieldName]_gtIntGreater than
[fieldName]_lteIntLess than or equal to
[fieldName]_gteIntGreater than or equal to
{
products(where: { quantity: 100 }) {
quantity
}
multipleQuantities: products(where: { quantity_in: [10, 100, 1000] }) {
quantity
}
}

#Float

All Float fields can be filtered using:

MatchesTypeBehavior
[fieldName]_notFloatNot this (null excepted)
[fieldName]_in[Float]One of
[fieldName]_not_in[Float]Not one of
[fieldName]_ltFloatLess than
[fieldName]_gtFloatGreater than
[fieldName]_lteFloatLess than or equal to
[fieldName]_gteFloatGreater than or equal to
{
products(where: { rating: 4.5 }) {
name
rating
}
}

#Boolean

All Booleans belonging to your content model can be filtered using the field name directly, as well as appended with _not, with a Boolean input type.

MatchesTypeBehavior
[field]BooleanIs
[field]_notBooleanFlips boolean (null not taken into account)

For example, let's filter posts where the custom field verified is true:

{
posts(where: { verified: true }) {
id
}
posts(where: { verified_not: true }) {
id
}
}

#Date

All Date fields can be filtered using:

MatchesTypeBehavior
[fieldName]_notDateNot this (null excepted)
[fieldName]_in[Date]One of
[fieldName]_not_in[Date]Not one of
[fieldName]_ltDateLess than
[fieldName]_gtDateGreater than
[fieldName]_lteDateLess than or equal to
[fieldName]_gteDateGreater than or equal to
{
today: events(where: { day: "2020-10-07" }) {
day
}
upcoming: events(where: { day_gt: "2020-10-07" }) {
day
}
}

#DateTime

Hygraph stores Date/DateTime fields as UTC strings, ISO 8601.

Like Date fields, DateTime fields can be filtered using:

MatchesTypeBehavior
[fieldName]_notDateTimeNot this (null excepted)
[fieldName]_in[DateTime]One of
[fieldName]_not_in[DateTime]Not one of
[fieldName]_ltDateTimeLess than
[fieldName]_gtDateTimeGreater than
[fieldName]_lteDateTimeLess than or equal to
[fieldName]_gteDateTimeGreater than or equal to
{
events(where: { start: "2020-10-07T09:00:00+00:00" }) {
start
}
previous: events(where: { start_lt: "2020-10-07T09:00:00+00:00" }) {
start
}
}

#Basic Reference

All relations (except Unions) can be filtered using filters on the fields of the model you are referencing. You can filter where every, some, and none at all match the conditions provided.

MatchesBehavior
[fieldName]_everyEvery reference matches
[fieldName]_someSome references match
[fieldName]_noneNo references match

For example, you could fetch every post by the provided author name.

{
posts(where: { authors_every: { name_in: ["John", "Simona"] } }) {
title
authors {
name
}
}
}

#Null references

It is possible to filter on single, and multi reference fields for when these references are empty.

  • [fieldName]_every: {}: Returns all authors, with or without connected posts
  • [fieldName]_some: {}: Returns all authors with at least one connected post
  • [fieldName]_none: {}: Returns all authors that have no posts connected

#Union reference

Using the where filter, you can filter by unions to get into the models and even fields inside of them.

You can combine the where filter with the following:

MatchesTypeBehavior
[FieldName]_emptyBooleanIf true, it returns every result where the filtered union is not connected / is empty
[FieldName]_someArrayMatches if the union contains at least one connection to the item provided to the filter

#Nested unions

Using filters allows going into the reverse field and getting information from the start model.

#Basic component

#Basic component field allows multiple values

All basic component fields that allow multiple values can be filtered using:

MatchesBehaviour
[fieldName]_everyEvery reference matches
[fieldName]_someSome references match
[fieldName]_noneNo references match

#Basic component field doesn't allow multiple values

If the basic component field does not allow multiple values, the _every, _some, and _none filters are unavailable, but you can query for a match as well as for empty components.

#Modular component

All modular component fields that allow multiple values can be filtered using:

MatchesTypeBehavior
[FieldName]_emptyBooleanIf true, it returns every result where the filtered model is empty
[FieldName]_someArrayMatches if the model contains at least one connection to the item provided to the filter

#Nested components

You can use the above filters to filter data from different levels of nested components as follows:

#Enumeration

All Enum fields can be filtered by using:

MatchesTypeBehavior
[fieldName]_notEnumerationValueNot this (null excepted)
[fieldName]_in[EnumerationValue]One of
[fieldName]_not_in[EnumerationValue]Not one of
[fieldName]_ltEnumerationValueLess than
[fieldName]_gtEnumerationValueGreater than
[fieldName]_lteEnumerationValueLess than or equal to
[fieldName]_gteEnumerationValueGreater than or equal to

The type of enumeration you can filter by will be the actual Enumeration values defined in your schema.

{
resources(where: { type_in: [Webinar, Ebook] }) {
id
}
}

#Asset

All Asset fields can be filtered using:

MatchesTypeBehavior
[fieldName]_notStringNot this (null excepted)
[fieldName]_in[String]One of
[fieldName]_not_in[String]Not one of
[fieldName]_ltStringLess than
[fieldName]_gtStringGreater than
[fieldName]_lteStringLess than or equal to
[fieldName]_gteStringGreater than or equal to
[fieldName]_everyRelation TypeEvery reference matches
[fieldName]_someRelation TypeSome references match
[fieldName]_noneRelation TypeNo references match

Asset fields come with their own System Fields which you can apply these filters on, as well as any custom fields, or references you add.

You can filter the asset through the reference, or when querying all assets.

For example, we could fetch posts where the coverImage field meets the provided criteria on the system field fileName:

{
posts(where: { coverImage: { fileName: "image.png" } }) {
id
coverImage {
fileName
}
}
}

#Combining filters

Just like combining query arguments, it is also possible to combine filters.

{
events(
where: {
start_gt: "2020-10-01T09:00:00+00:00"
start_lt: "2020-10-31T09:00:00+00:00"
fancyDress: true
price: 100
}
) {
start
fancyDress
price
}
previous: events(where: { start_lt: "2020-10-07T09:00:00+00:00" }) {
start
}
}

#Conditional filters

Hygraph supports conditional filters for your content using AND, NOT and OR. Useful for filtering results based on more than one criteria.

Input TypeDescription
ANDFetch entries that meet both conditions.
ORFetch entries that match either condition.
NOTFetch all entries where the conditions do not match.

#Filter by locales

When querying content entries, you can also filter by locales:

{
posts(locales: [en]) {
id
}
}

Learn more about localization.

#Filter by stage argument

When querying content entries, you can also filter by stage. The stage argument decides what document variation gets returned and searched through. Therefore, if the document does not exist in the stage variation, it gets filtered out.

{
posts(stage: PUBLISHED) {
id
stage
}
}

Learn more about content stages.

#Filter by content stage

Stages work a bit differently in the API than in the UI. In the UI, we use the most intuitive and editor-friendly way of treating filters. So, for instance, if you see a green PUBLISHED pill next to an entry, then this entry is only in the PUBLISHED stage. However, in the backend, our stages are organized slightly differently. The main difference is that each content entry always exists in DRAFT, and other stages are added or removed. For example, an entry that has a green PUBLISHED pill in the UI is actually in both DRAFT and PUBLISHED stages on the API side, and both versions of the entry are identical. If you update the DRAFT version but don't publish it, the entry will continue to exist in both stages, but will be marked as blue PUBLISHED in the UI.

Stages can be filtered using:

MatchesBehavior
documentInStages_everyAll existing stage variations must match the sub-filter
documentInStages_someAt least one of the existing stage variations must match the sub-filter
documentInStages_noneNone of the existing stage variations are allowed to match the sub-filter

To summarize, like we mentioned before, a document will always exist in the DRAFT stage, and they may or may not exist in other published stages such as PUBLISHED or for example QA - which is a custom content stage that can be published to.

If you, as a user, want to find documents that exist in the PUBLISHED stage, you can run the following query:

stage: DRAFT
where: {
documentInStages_some: {
stage: PUBLISHED
}
}

The above documentInStages_some allows the user to find documents which exist in a different stage. Let's consider the following 3 documents, which exist in the following stages:

IDSTAGES
cldocument1[DRAFT, PUBLISHED]
cldocument2[DRAFT]
cldocument4[DRAFT, PUBLISHED, QA]

The above query will return documents that also exist in the PUBLISHED stage, which are cldocument1 and cldocument4.

However you may have noticed that cldocument4 also has been published to the QA stage - If you have access to custom stages.

Imagine you want to query documents which exist only in one published stage PUBLISHED, but not any other publishable stages. In this case the result you want is cldocument1. For this we can use documentInStages_every.

Keeping in mind that a document entry can exist in multiple stages, the difference between documentInStages_some and documentInStages_every is that documentInStages_some checks if an entry exists in a particular stage, whereas by using documentInStages_every we request an entry that exists in only and exactly that stage. So if we use documentInStages_every with PUBLISHED the query will return results only if the document exists in PUBLISHED and no other stage.

You might read this and try a query such as the following:

where: {
documentInStages_every: {
stage: PUBLISHED
}
}

While you are on the right track, this will unfortunately return no results. The reason is that, as we mentioned earlier, every document always exists in DRAFT, so no document will ever only exist in PUBLISHED.

If you try changing the above PUBLISHED to DRAFT, however, you will get cldocument2 as a result, as this document only exists in the DRAFT stage.

As a workaround for this problem, we can use the OR meta filter, by using the following query:

where: {
documentInStages_every: {
OR: [
{
stage: DRAFT
},
{
stage: PUBLISHED
}
]
}
}

Since the internal query is that the stage must exist either in DRAFT or PUBLISHED, the query evaluates to true for both document cldocument1 and cldocument2. It skips cldocument4, which is what we want, but we still get cldocument2 which exists only in DRAFT.

We can use the same pattern of using meta filters to filter out the DRAFT entry. Let's start by writing this query:

where: {
NOT: [
{
documentInStages_every: {
stage: DRAFT
}
}
]
}

As you can see, this query returns any document that does not exist only in DRAFT, Which in this case would be cldocument1 and cldocument4. If we were to do an intersection of the results of the above two queries, we would get cldocument1, which is the document that we want.

In order to do this, we combine the above two queries to create the following:

where: {
AND: [
{
documentInStages_every: {
OR: [
{
stage: DRAFT
},
{
stage: PUBLISHED
}
]
}
},
{
NOT: [
{
documentInStages_every: {
stage: DRAFT
}
}
]
}
]
}

As you can see above, by using the AND meta filter we get the intersection between the two queries above, which returns the cldocument1 document.

compareWithParent

compareWithParent allows the comparison of a document with its parent entry using any comparison operators available within it.

At the moment compareWithParent is available only inside a documentInStages_* filter, and only allows the use of one attribute which is outdated_to. This attribute can be found inside the compareWithParent filter. The attribute is used to specify if we wish to check whether the child document is outdated compared to the parent document. For example:

variousDocuments(
stage: DRAFT
where: {
documentInStages_some: {
stage: PUBLISHED
compareWithParent: {
outdated_to: true
}
}
}
)

In the above example, we enable the filter by setting outdated_to to true - if it were set to false, it would be the same as having the filter omitted entirely. The true and false values are simply indicators of whether to process the filter in the query.

In the above query, we check if the child PUBLISHED version is outdated compared to the DRAFT parent version. At the moment, we check if a document is outdated by comparing the updatedAt attributes of both the DRAFT and PUBLISHED versions. If the DRAFT has a greater updatedAt, that means the document has been modified since it was last published, and is therefore considered outdated.

#JSON filtering

You can filter the data in the JSON fields of your Hygraph project using the following filters.

#value_recursive

You can filter the data in your JSON fields by using the following value_recursive syntax to find exact matches:

query for {
posts(where: { jsonField_value_recursive: "hallo" }) {
id
jsonField
}
}

The query above would search the JSON fields for an exact match of "hallo" on all values, excluding the json keys.

#json_path_exists

You can filter the data in your JSON fields by using json_path_exists syntax from PostgreSQL.

To be able to query this content, you need to know the JSON structure to navigate through it.

If you're not familiar with the structure, you can query for all content - without passing a filter, or with just a pagination filter depending on number of entries - and look into it. A great way to go about this kind of exploration is using the API Playground, where you can type “json” then use ctrl + space or command + space to display all the filters you can use and select one.

#Query syntax examples

Imagine we have the following content data in a JSON field which allows multiple values:

"data": {
"testFieldsModels": [
{
"listJsonField": [
{
"items": {
"qty": 24,
"product": "Diaper"
},
"customer": "Lily Bush"
},
{
"items": {
"qty": 1,
"product": "Toy Car"
},
"customer": "Josh William"
},
{
"items": {
"qty": null,
"product": "Headphones"
},
"customer": "James Buyer"
}
]
}
]
},

Using the above sample content data, here are some query examples:

 

Query by quantity

You can use "$[*].** ? (@ > N)” to filter all values all for integers above a certain number. Just replace N with the number of your choice.

query for {
testFieldsModels(
where: { listJsonField_json_path_exists: "$[*].items.qty ? (@ > 5)" }
) {
listJsonField
}
}

The above query example returns products with a quantity greater than 5.

 

Query by string

You can use "$.** ? (@ == \"String\")” to filter all values all for the matching string:

query for {
testFieldsModels(
where: {
listJsonField_json_path_exists: "$.items.product ? (@ == \"Toy Car\")"
}
) {
listJsonField
}
}

The above query example returns products with the name “Toy Car”.

 

Query by null

You can use "$[*].** ? (@ == null)” to filter all values all for null.

query for {
testFieldsModels(
where: { listJsonField_json_path_exists: "$[*].items.qty ? (@ == null)" }
) {
listJsonField
}
}

The above query example returns items where quantity (qty) = null.

 

Query by range

You can use "$[*].** ? (@ > N && @ < N)” to filter all values all for a range of numbers. Just replace N with the numbers of your choice.

query for {
testFieldsModels(
where: {
listJsonField_json_path_exists: "$[*].items.qty ? (@ > 1 && @ < 5)"
}
) {
listJsonField
}
}

The above query example returns items with a quantity between 1 and 5.