Skip to content

Allow providing additional types to schema build.#33

Merged
andimarek merged 2 commits into
graphql-java:masterfrom
zourzouvillys:additional-types-in-schema
Sep 25, 2015
Merged

Allow providing additional types to schema build.#33
andimarek merged 2 commits into
graphql-java:masterfrom
zourzouvillys:additional-types-in-schema

Conversation

@zourzouvillys
Copy link
Copy Markdown
Contributor

With the current API, only concrete instances which are registered somewhere from the query or mutation root are registered. This makes writting tools to automatically generate types a PITA - specifically because you have to ensure there is at least one concrete instance of every type registered.

This change provides a way to pass a set of types into the schema when building it, which will be added into the set of available types when replacing type references.

An alternative could be to provide a resolver to GraphQLTypeReference, which would be used to resolve the type at build time - however, this method seems far less intrusive for existing consumers :-)

With the current API, only concrete instances which are registered
somewhere from the query or mutation root are registered.  This makes
writting tools to automatically generate types a PITA - specifically
because you have to ensure there is at least one concrete instance of
every type registered.

This change provides a way to pass a set of types into the schema when
building it, which will be added into the set of available types when
replacing type references.

An alternative could be to provide a resolver to GraphQLTypeReference,
which would be used to resolve the type at build time - however, this
method seems far less intrusive for existing consumers :-)
@andimarek
Copy link
Copy Markdown
Member

Thanks!

Is this PR related to this one https://github.com/andimarek/graphql-java/pull/28 in your opinion?

To understand the use-case better: Do I understand this right, that you generate the schema automatically and sometimes you have for example a InterfaceType and a some ObjectTypes implementing this Interface, but nobody is referencing the ObjectType, just the Interface?

@zourzouvillys
Copy link
Copy Markdown
Contributor Author

It's not directly related to #28.

re use case: yes. the one that bit me was using a TypeReference everywhere a given type if mentioned is used (e.g, in parameters or return types), and so when it comes to building the schema, there is no reference to the actual ObjectType instance.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would prefer not to use null ... just a empty set

and then assert that its not null

@andimarek
Copy link
Copy Markdown
Member

ok ... I understand .... interesting approach to use TypeReference as default.

I comment on some minor issues I thought could be improved, but nothing seriously.

@zourzouvillys
Copy link
Copy Markdown
Contributor Author

pushed and update re null instead of empty set usage!

andimarek added a commit that referenced this pull request Sep 25, 2015
Allow providing additional types to schema build.
@andimarek andimarek merged commit 0c69290 into graphql-java:master Sep 25, 2015
@andimarek
Copy link
Copy Markdown
Member

Thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants