Making a field in graphql schema required

I have…

I’m submitting a…

  • [ ] Regression (a behavior that stopped working in a new release)
  • [ ] Bug report
  • [ ] Performance issue
  • [x] Documentation issue or request

Current behavior

When we create a field for any entity and we mark the field as required it is still shown as optional in GraphQL schema

Expected behavior

Once the field is marked as required the schema should reflect it (ie - the exclamation mark in field graphql definition)

Minimal reproduction of the problem

Create an entity, create a simple text field, mark it as required, do an graphql introspection query of the schema - the field is still optional

Environment

  • [ ] Self hosted with docker
  • [ ] Self hosted with IIS
  • [ ] Self hosted with other version
  • [x] Cloud version

Version: current cloud version

Browser:

  • [ ] Chrome (desktop)
  • [ ] Chrome (Android)
  • [ ] Chrome (iOS)
  • [ ] Firefox
  • [ ] Safari (desktop)
  • [ ] Safari (iOS)
  • [ ] IE
  • [ ] Edge

Others:

Hi,

the problem is the graphql server. When a field is required it has to be required in the output as well.

Lets say you execute the following steps:

  1. Create a a schema with a field
  2. Create a few content items where some of the fields are required and others not.
  3. Mark the field as required.
  4. Query the content with GraphQL

Then the GraphQL server (not the Client) would throw an exception.

In relational databases step 3 would fail, but in Squidex and document based databases this constraint is only check when the data is being inserted.

Side note on this particular issue. At first I wanted this to be required as well but I actually think it being optional in GraphQL is helpful.

When you use Apollo later to do code generation of the GraphQL query, by having it be optional, if you change the status in squidex to required/optional at any time it doesn’t impact your current code base.

1 Like

I see your point - but with that assumption we could make everything nullable just to give that flexibility should we want to change it in the future, no?

@Sebastian you see - to me that is exactly what should happen - if the data is missing a required field it should either throw an exception or never actually be there in the first place. Perhaps when making a field required squidex should look up all the records to see if the operation is permitted? Or do a quick migration, maybe allow for some default input or something just to migrate all the historic data?

This is what a relational database does. But it has a lot of costs. For example you need a global lock across all servers to ensure that nobody changes content for the schema when doing something like this and when you have a lot of records it takes a while.