refactor: Extract query schema errors to dedicated file

[AndrewSisley]

Relevant issue(s)

Part of #257

Description

Extracts query schema errors to dedicated files (includes mapper). Continuation of work done at the end of last year whilst waiting on other discussions to progress.

[codecov]

Codecov Report

Merging #1037 (f5003b4) into develop (210423c) will decrease coverage by 0.03%.
The diff coverage is 18.75%.

@@             Coverage Diff             @@
##           develop    #1037      +/-   ##
===========================================
- Coverage    57.78%   57.75%   -0.03%     
===========================================
  Files          173      174       +1     
  Lines        19495    19521      +26     
===========================================
+ Hits         11265    11275      +10     
- Misses        7235     7251      +16     
  Partials       995      995              

Impacted Files	Coverage Δ
query/graphql/schema/descriptions.go	91.66% <0.00%> (+2.84%)	⬆️
query/graphql/schema/relations.go	58.67% <0.00%> (ø)
query/graphql/schema/errors.go	22.22% <22.22%> (ø)
query/graphql/schema/generate.go	82.83% <22.22%> (+1.22%)	⬆️

[jsimnz]

Left a note about the "generic" error type from the client package.

[jsimnz]

suggestion: I know the use of generics for this particular err type is from before, but the more I see it the more I don't like it :/

I could just as easily be client.NewErrUnexpectedType("operatortype", &gql.InputObject{}, operatorType), no?

[AndrewSisley]

:) Why would you instantiate a whole object (at runtime) just for a type declaration?

[jsimnz]

I mean, its the error path, so allocation/perf isn't the highest priority, besides you allocate it anyway within the func.

[jsimnz]

I'd prefer to leave generics when we know we really want to maintain type safety. I don't see that as a requirement in this particular use case.

[AndrewSisley]

Generics are not just for type safety :)

My 'Why would you...' comment isn't really just about performance. An object is a 'thing', and that thing lives in the runtime space and is mutable/variable. A type declaration is a compile-time constant and never changes. By defining as much as possible at compile time you can reduce the amount of variation in a system.

That said, this also smells like personal preference, and scope creep as if I was to change this here I'd have to expand this PR to cover every line that touches this function. I also don't think it would make sense to slow the merge of this PR for this even if we were in agreement that it should change in the very near future.

[fredcarle]

I don't really see why the use of generics here wouldn't be appropriate. I suggest we take this conversation to a Discord thread as it's out of scope of this PR. John, if you really think we shouldn't do that, I would love to have your thoughts explained in the Discord thread.

[jsimnz]

Agreed on scope, was raised here its was the N'th time it poked me. Doesn't need to block the merging.

[AndrewSisley]

• Create issue to change this

[jsimnz]

lgtm