-
Notifications
You must be signed in to change notification settings - Fork 2k
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
buildASTSchema() should throw on encountering extend
definition
#922
Comments
Out of curiosity: is there something that prevents supporting For example this definition: type Queries {
querySubset: QuerySubset
}
type Query {
queries: Queries
}
extend type Queries {
hello: String
} Look semantically correct to me. When used in this form in may look a bit unusual, but the last definition could be loaded from a different file. From what I can tell, supporting |
That would be new behavior, but I'd also be happy to entertain PRs adding that as well. If so, the same change should probably be made in extendSchema if multiple extend statements are found, and care should be put into ensuring that the order in which the extensions are applied result in the same output. |
I think this might be a breaking change for graphql-tools. I believe the way it currently does schema extension concatenates a number of schema language strings together and then pulls the extensions out to add them in a second step. I agree with @OlegIlyenko about looking for a solution that handles the extensions and perhaps warning on this case in the mean time. |
Hey I would like to chip in on this one. Can I first take up the issue of adding a warning? Then I will try to understand and help implement handling |
Does extend work now? @leebyron The upside I'm seeing is as such allowing people building graphql application to modularize their application schema. |
For usecase where somebody needs multiple files merge up to one AST I write this helper: https://gist.github.com/langpavel/9653b99afe993167fc4bacafbfcc7909 What it can do:
really not much of code with this possibilities, look on gist :-) |
Hello, appreciate the work all of you do here. Just curious, when is the fix for this expected to be released? |
@aishwar Thanks. |
I've been flipping around 10+ issues on this topic, and I'd like some clarification: does Object extension actually work per the spec in the current version of this reference JS implementation, or is it undocumented because it only partially works (i.e. schema can be defined, but extended fields can't be queried)? (To further muddy the waters, extending types does work with graphql-tools.) If it does work, what am I doing wrong in this example that I'm getting this error?
|
Current implementation already fully support extensions using const { graphql, parse, buildSchema, extendSchema } = require('graphql');
let schema = buildSchema(`
type Person {
name: String!
}
type Query {
person: Person
}
`);
schema = extendSchema(schema, parse(`
extend type Person {
salary: Int
}
`));
var root = { person: () => ({ name: "John Doe", salary: 1234 })};
graphql(schema, '{ person {salary} }', root).then((response) => {
console.log(response);
});
Thanks for example 👍 |
buildASTSchema()
exists to parse a fully complete schema definition and produce a schema. However currently if it encounters anextend
definition, or any other definition it does not use for that matter, it silently skips over it. This can lead to a confusing debugging situation.Instead,
buildASTSchema()
should throw when it encounters a definition that it does not use, similar to howexecute()
throws if a the provided document contains any definition other than operations.The text was updated successfully, but these errors were encountered: