Support a custom Schema.query_class #4679
Conversation
| validator_opts = { schema: self } | ||
| rules && (validator_opts[:rules] = rules) | ||
| validator = GraphQL::StaticValidation::Validator.new(**validator_opts) | ||
| res = validator.validate(query, timeout: validate_timeout, max_errors: validate_max_errors) | ||
| res[:errors] | ||
| end | ||
|
|
||
| def query_class(new_query_class = NOT_CONFIGURED) | ||
| if NOT_CONFIGURED.equal?(new_query_class) | ||
| @query_class || (superclass.respond_to?(:query_class) ? superclass.query_class : GraphQL::Query) |
There was a problem hiding this comment.
Is it worth remembering this outcome?
There was a problem hiding this comment.
That's a big question all around this library... what should happen in cases like:
BaseSchema.query_class = CustomQuery1
ChildSchema = Class.new(BaseSchema)
ChildSchema.query_class # CustomQuery1
# Then:
BaseSchema.query_class = CustomQuery2
ChildSchema.query_class # What should this return?I'd expect it to return the inherited value, CustomQuery2, not the previously inherited value, CustomQuery1.
On the one hand, I wouldn't expect situations like this to happen often, but on the other hand, with Rails autoloading, and with Ruby being Ruby, I'd want to stay open to it!
So that's why I didn't memoize the result. What do you think?
There was a problem hiding this comment.
Fair point, probably not worth it at this time.
Our internal implementation has class_attribute :query_class, default: GraphQL::Shopify::Query currently (we were ok with the dependency on activesupport) which handles this case.
Fixes #4354