New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Validate schema root types and directives #1124

Merged
merged 1 commit into from Dec 8, 2017

Conversation

Projects
None yet
4 participants
@leebyron
Collaborator

leebyron commented Dec 7, 2017

This moves validation out of GraphQLSchema's constructor (but not yet from other type constructors), which is responsible for root type validation and interface implementation checking.

Reduces time to construct GraphQLSchema significantly, shifting the time to validation.

This also allows for much looser rules within the schema builders, which implicitly validate while trying to adhere to flow types. Instead we use any casts to loosen the rules to defer that to validation where errors can be richer.

This also loosens the rule that a schema can only be constructed if it has a query type, moving that to validation as well. That makes flow typing slightly less nice, but allows for incremental schema building which is valuable

Improves #1079
Partial #1080
Closes #722

@leebyron

This comment has been minimized.

Show comment
Hide comment
@leebyron

leebyron Dec 7, 2017

Collaborator

This builds atop @kassens's fed9610

Collaborator

leebyron commented Dec 7, 2017

This builds atop @kassens's fed9610

Show outdated Hide outdated src/execution/execute.js Outdated
@IvanGoncharov

This comment has been minimized.

Show comment
Hide comment
@IvanGoncharov

IvanGoncharov Dec 7, 2017

Collaborator

@leebyron Wow, you did a lot of work to search for correct error location both in astNode and extensionASTNodes 👍

Having queryType optional makes #817 more feasible and I will rebase it after this PR will be merged.

Collaborator

IvanGoncharov commented Dec 7, 2017

@leebyron Wow, you did a lot of work to search for correct error location both in astNode and extensionASTNodes 👍

Having queryType optional makes #817 more feasible and I will rebase it after this PR will be merged.

@kassens

This comment has been minimized.

Show comment
Hide comment
@kassens

kassens Dec 8, 2017

Contributor

Really excited about this. The one thing that seemed not 100% ideal was the any casts, but I suppose the only way around that would to actually have different types for validated and unvalidated schema which would be a breaking change.

Contributor

kassens commented Dec 8, 2017

Really excited about this. The one thing that seemed not 100% ideal was the any casts, but I suppose the only way around that would to actually have different types for validated and unvalidated schema which would be a breaking change.

@kassens

kassens approved these changes Dec 8, 2017

@leebyron

This comment has been minimized.

Show comment
Hide comment
@leebyron

leebyron Dec 8, 2017

Collaborator

Yeah, casting to any makes me feel bad inside, but it's the right thing to do here. I'll add some comments there explaining what's happening.

Collaborator

leebyron commented Dec 8, 2017

Yeah, casting to any makes me feel bad inside, but it's the right thing to do here. I'll add some comments there explaining what's happening.

Validate schema root types and directives
This moves validation out of GraphQLSchema's constructor (but not yet from other type constructors), which is responsible for root type validation and interface implementation checking.

Reduces time to construct GraphQLSchema significantly, shifting the time to validation.

This also allows for much looser rules within the schema builders, which implicitly validate while trying to adhere to flow types. Instead we use any casts to loosen the rules to defer that to validation where errors can be richer.

This also loosens the rule that a schema can only be constructed if it has a query type, moving that to validation as well. That makes flow typing slightly less nice, but allows for incremental schema building which is valuable

@leebyron leebyron merged commit 819a59c into master Dec 8, 2017

3 checks passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
continuous-integration/travis-ci/push The Travis CI build passed
Details
coverage/coveralls Coverage decreased (-0.02%) to 98.634%
Details

@leebyron leebyron deleted the validate-top-level-schema branch Dec 8, 2017

@patrick91 patrick91 referenced this pull request Jan 3, 2018

Closed

Support for imports #80

@OlegIlyenko OlegIlyenko referenced this pull request Feb 4, 2018

Closed

Verify: some minor changes to the ref. impl. #311

13 of 13 tasks complete

danez pushed a commit to danez/graphql-php that referenced this pull request Feb 15, 2018

Daniel Tschinder
Validate schema root types and directives
This moves validation out of GraphQLSchema's constructor (but not yet from other type constructors), which is responsible for root type validation and interface implementation checking.

Reduces time to construct GraphQLSchema significantly, shifting the time to validation.

This also allows for much looser rules within the schema builders, which implicitly validate while trying to adhere to flow types. Instead we use any casts to loosen the rules to defer that to validation where errors can be richer.

This also loosens the rule that a schema can only be constructed if it has a query type, moving that to validation as well. That makes flow typing slightly less nice, but allows for incremental schema building which is valuable

ref: graphql/graphql-js#1124

@danez danez referenced this pull request Feb 16, 2018

Merged

Port 0.12.3 changes from graphql-js #248

0 of 45 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment