Changes to schema generation impact some GraphQL filters

[bwlng]

Brief bug description

Before automatic schema generation was implemented, it was possible to filter the usedByContentItems property. For example, to show related content where the linked items relationship is made on another entry, you could use the usedByContentItems parameter to retrieve the content so the relationship didn't have to be maintained on multiple entries.

export const query = graphql`
  query BeltIdentifierTypeQuery(
    $url_slug: String!
    $language: String!
  ) {
    pitches: allKontentItemBeltPitch(
      filter: {
        usedByContentItems: {
          elemMatch: {
            system: { type: { eq: "belt_series" } }
            elements: {
              belt_type: {
                linked_items: {
                  elemMatch: {
                    elements: { url_slug: { value: { eq: $url_slug } } }
                  }
                }
              }
            }
          }
        }
      }
    ) {
      nodes {
        id
        elements {
          pitch {
            value
          }
        }
        beltSeries: usedByContentItems {
          ... on KontentItemBeltSeries {
            id
            system {
              type
              language
            }
            elements {
              title {
                value
              }
              url_slug {
                resolvedUrl
              }
            }
          }
        }
      }
    }
  }
`

The query above fails w/ Field "elements" is not defined by type KontentItemFilterInput.

A similar error occurs with otherLanguages in the following query:

export const query = graphql`
  query QueryName(
    $url_slug: String!
    $language: String!
  ) {
    entry: kontentItemBeltSeries(
      preferred_language: { eq: $language }
      elements: {
        url_slug: { value: { eq: $url_slug } }
        belt_identifier_entries: {
          linked_items: {
            elemMatch: {
              otherLanguages: {
                elemMatch: { preferred_language: { in: ["en", "de"] } }
              }
            }
          }
        }
      }
    ) {
      system {
        type
        language
        codename
      }
    }
  }
`

The query above fails w/ Field "otherLanguages" is not defined by type KontentItemFilterInput. Did you mean preferred_language?

It appears the regression occurs somewhere between 4.0.0-beta2 and 4.2.0 — I think related to the automatic schema generation.

Is there something I can fine-tune on the query or another workaround that doesn't affect the content model in Kentico?

Possibly related to the following: #84 , #105

Expected behavior

The query should retrieve data as it did before the schema generation process was updated.

Test environment

• @kentico/gatsby-source-kontent v4.3.0
• @kentico/kontent-delivery v9.0.0

[makma]

Hi @bwlng thank you for letting us know. I'm not sure about usedByContentItems (@Simply007 should know better), however, in my opinion missing other languages property is a bug. We will let you know!

[Simply007]

Hello @bwlng,

thanks for submitting this. This is caused by the filter is using KontentItem interface that does not have most of the elements defined, because they are defined in inherited types.

Unfortunately, I haven't found any GraphQL possibilities to type this filter using inline fragment, nor the gatsby documentation according to the input filter and their potential inferring is not up to date.

On the other hand, I have tried a more clean way how to precompute some data to fields in OnCreateNode lifecycle method.

The solution is in the https://github.com/Simply007/schema-definition-changes repository

You might want to use any other lifecycle method (https://www.gatsbyjs.org/docs/node-apis/#gatsby-node-apis) by the specific use case. Or even setFieldsOnGraphQLNodeType if it suits you.

In my opinion, this might be also beneficial according to the performance of running queries described in #107, but it is just a guess, the performance peaks must be identified first - but worth a try!

[Simply007]

According to the vision - we would like to extract the functionality of the "computed" properties from the source plugin and describe how to implement them right in the application or provide the transformers plugin if the property would be heavily used.

See #108

[bwlng]

Thanks for the workaround @Simply007. I can confirm that precomputing the data I'm filtering on as outlined in the schema-definition-changes repo is a good workaround for the properties that can't be filtered using KontentItem interface.

This doesn't affect the query performance described in #107, but as stated in that issue, the Gatsby team is aware and thinks it may be a regression on their end.

[Simply007]

Great to hear @bwlng!

I am closing the issue for now.

If we missed anything on this issue or if you want to keep it open, feel free to do so.