Implement "extend type ..."

[mikroskeem]

http://spec.graphql.org/June2018/#sec-Object-Extensions

[mikroskeem]

While seems like there's some sort of a support present, then it doesn't seem to function at all.

Example schema:

type Query {}

extend type Query {
    servers: [String!]!
}

schema {
    query: Query
}

Example query:

query {
    servers
}

And I'll get back field 'servers' is not defined on type 'Query'

[mikroskeem]

Introspection also reveals that indeed said field is not present:

query {
  __type(name: "Query") {
    name
      fields {
        name
          type {
            name
              kind
          }
      }
  }
}

{
  "data": {
    "__type": {
      "name": "Query",
      "fields": []
    }
  }
}

[tendant]

Thanks for reporting the issue.

This part of spec has not been implemented yet. To implement it, we need to enhance the parser and possibly the execution engine to support it.

Can I ask what is the particular use case you are trying to archive with this feature?

[mikroskeem]

My use case is to split up large definitions into multiple files, which I load from the classpath or somewhere else.

Let's say I have User type. Right now I'll expose first/lastname in user.graphql, then later create family.graphql where I'll have types which describe family members and extend User to expose its family.

[tendant]

Looks like in such case, the only thing missing is to support it during parsing phase.

Will it be sufficient to require user to concatenate multiple graphic schema files before it is passed to graphql parser?

I need look into how to support it in parser based on the spec. Thanks for bringing up this issue.

[mikroskeem]

Will it be sufficient to require user to concatenate multiple graphic schema files before it is passed to graphql parser?

Mind bringing an example? Or do you think literally concatenating the files into single string blob? If latter, then I'm perfectly fine with it, because I'm doing that right now.

[tendant]

Yes. Just literally concatenating the files into single string.

It is easy to implement without changing any existing functionality. The downside is that the error reporting on line number of a graphql schema will be incorrect.