A schema with all deprecated elements removed must itself be valid#1231
A schema with all deprecated elements removed must itself be valid#1231benjie wants to merge 1 commit into
Conversation
|
cc @fotoetienne |
✅ Deploy Preview for graphql-spec-draft ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
Should this go along with a change to allow empty objects? |
|
I don't think it needs to be, but in an ideal world they'd all be merged together. |
| 2. Let {implementedFieldType} be the return type of {implementedField}. | ||
| 3. {IsValidImplementationFieldType(fieldType, implementedFieldType)} must | ||
| be {true}. | ||
| 6. If {field} is deprecated then {implementedField} must also be deprecated. |
There was a problem hiding this comment.
imho we should leave this in place though as an implementation of the new definition you've added above?
I don't think the spec should leave various ways in which the subset-is-valid needs to be looked out for
separately, I think removing this actually says something else-- that an interface field being deprecated may differ from the deprecation status of an implemented field? -- that could be a separate proposal if that's what we want to explore
| If a GraphQL schema contains any deprecated _schema element_, a copy of the | ||
| schema that omits all deprecated _schema element_ must itself be valid. |
There was a problem hiding this comment.
Maybe: "A copy of a GraphQL schema that omits every deprecated schema element must itself be valid."
A schema with no deprecated elements will be trivially valid. Also making sure _schema element_ is pluralized correctly.
As a precursor to deprecating other schema elements (object types, etc), I figured it would be best to simplify the rule: the schema with all deprecated elements removed should itself be valid. This is a breaking change for servers currently (could mark a previously valid schema as invalid), but solvable in a non-breaking way by removing
@deprecateddirectives, or (once they are supported) adding@deprecatedto object types and other positions. It's non-breaking for clients.This also aligns with #1230 wherein the schema with all deprecated elements removed is represented via
{ __schema(includeDeprecated: false) { ... } }.