More Constraints

[sorenbs]

Make field constraints much more flexible.
This feature can probably be delivered in smaller chunks

Use case 1

A phone number field should match a regex

Use case 2

A phone number field should be required if and only if the roles field is STORE_MANAGER

Use case 3

A money field should only allow prime numbers

[OlegIlyenko]

I have another use-case: email and URL validation. I think these are pretty common so it would be nice to have a dedicated validators for them (though it is possible to express it via regexp)

[marktani]

Might be also handled by pre-mutation function calls

[ejoebstl]

Thoughts:

• This approach somehow breaks the typing approach of graphql, since an mutation might still fail even if the data types were correct. On the other side, that's a general problem of universal data types like strings.
• The user will only be able to map very basic use cases to regex. Especially, this kind of validation does not take other nodes into account. On the other side, regex is well understood, simple and fast.
• I very much like the idea of pre-mutation hooks as in Synchronous Mutation Callback #58 for more complex validation cases.

[lovegrovegeorge]

@ejoebstl Massive one up on pre-mutation hooks. Would complete the ability to do any logic you need before mutating something.

[marktani]

Another common use case:

• a String should not be empty

more inspiration: https://github.com/aldeed/meteor-simple-schema

[marktani]

Another use case:

• unicity across models Unicity across different models #24

[PierBover]

What about a constrain that specifies that if a type has 3 fields, at least one of them must be non null.

For example a Customer type wth these fields where at least one is required:

• Individual
• Organization
• School

[kbrandwijk]

Also see: https://github.com/APIs-guru/graphql-constraints-spec, maybe that's relevant for these use cases?

[marktani]

Closing in favor of #728.