Skip to content
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

Document schema.AddScalar(), AddEnum #50

Open
markhepburn opened this issue Oct 6, 2016 · 2 comments
Open

Document schema.AddScalar(), AddEnum #50

markhepburn opened this issue Oct 6, 2016 · 2 comments

Comments

@markhepburn
Copy link
Contributor

I'd submit a PR but I'm unclear exactly how it's used, myself :)

GraphQLSchema defines a method AddScalar, which has something to do with validating and translating scalar types.

It's used in the tests to add a DateTime with year/month/day components, but I'm a bit unclear where these components come from, since the translation is only in one direction.

Without it, tests that query a model with a DateTime field will fail; for eg, comment out the AddScalar line in EntityFrameworkExecutionTests.CreateDefaultContext(), or alternatively in EntityFrameworkExecutionTests.AddAllFields() add a query on account (in this test Account is defined via AddAllFields(), but without the DateTime scalar added to the schema):

gql.ExecuteQuery("{ account(id:1) { id } }");
@chkimes
Copy link
Owner

chkimes commented Oct 7, 2016

AddScalar only has one translation because it only ever needs to do one. We treat scalars as values that we could either receive as input to a query or return as output in a result set (which cannot have their own selection set, see: https://facebook.github.io/graphql/#sec-Scalars).

Our result sets are entirely in-memory, not serialized. This is so that you can pass them off to whatever serialization library you want (likely Newtonsoft.Json, but we're flexible). Given that, we have no need to provide a translation from a scalar type back to a string type.

However, since we parse the input query and can accept an arbitrary scalar, we have to be able to build that scalar up from components we understand (ints, floats, strings, etc.).

I intended to write some additional documentation this weekend (related to #46), so while I'm doing that I can add real documentation for these features as well.

@markhepburn
Copy link
Contributor Author

Aah, I see thanks, so it's in the query-parsing direction? That makes sense.

Why does it raise an exception though when you execute a query, if you're not parsing (or serialising) that field? (Obviously I haven't dug that deep into that bit of the code sorry, I was just curious at this point)

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

No branches or pull requests

2 participants