When dealing with client requests for other resolvers, it's normal for the graphql implementations to call whatever nested resolvers were asked for without you needing to do it manually. It seems like with gqlgen, you have to embed a lot of 'if' statements to manually call other resolvers. Imagine a 'well-connected' entity like a user account which might have 10 different checks to https://gqlgen.com/reference/field-collection/ to know what nested resolvers to call. Is this correct?
If I have a query like query { A { B { C { name } } } } do I have to embed if checks in A for B, and checks in B for C?
2 replies
https://github.com/99designs/gqlgen/discussions/2049
Is there a good resource for how to write a basic filter query while using gqlgen?
For example, if I wanted to filter all members by those with a given name, my schema might look like:
type Query {
members(name: String): [Member!]!
}How would one cleanly handle this in the resolver? It feels like we would have to check for the name input and then conditionally adjust the underlying SQL query based on the existence of that field by appending a WHERE name = ? clause. That feels so clunky, I'm quite convinced I'm missing something and that there's a better way....
enum Direction {
UP = "up",
DOWN = "down",
LEFT = "left",
RIGHT = "right",
}
If you want something that's a little more automatic in that mapping, try something like Hasura. (Not Go, though.)
([\w]+\.)+[\w]+([\s]|$)) then with a loop trying to match nested key and it value but it seem overload for me...instead can we move it the GePreloads(ctx) itself and try to have a work around? for example in rethinkdb pluck need {key: true, nested: {child: true}} to perform...can you guy point me a direction please!!!
I create a minimal schema (just a type and a query that returns that type) and run "go generate" on 0.17.2, and I get a bunch of errors that all say
generated.go:784:15: ec._fieldMiddleware undefined (type *executionContext has no field or method _fieldMiddleware)
Hi team
I am also getting same type of error while generating.
I think I may be misunderstanding something about how autobind works or have simply misconfigured something.
My impression is that setting it like this:
models:
Todo:
fields:
user:
resolver: trueMeans that gqlgen should look to the configured package for custom types already defined to resolve most fields for that type but then also that any explicit fields listed here with resolver: true will have a resolver generate for it regardless.
In my situation, I'm pointing gqlgen autobind package to sqlc-generated models but then resolvers are automatically being generated for far too many fields even when set to resolver: falsein the config for said field.
Any ideas on what I'm missing?
1 reply
ctx.Done into a goroutine and have it block until ctx.Done returns, so that you can read each message. Right now, that ctx.Done() is going to block and you'll only send one message over your channel.
Is it possible to have multiple models be used as the defaults for resolver arguments? For example, if I have two DB models that are effectively backing a single GQL type, is there a way to take the union of fields under the two DB types and have resolvers auto-resolve those?
The only way now seems to be to pick one type to auto-resolve for and then explicitly resolve the reset even if they're still basic scalars that could effectively be pass-through resolution.
I guess one issue with supporting multiple types is that it can get ambiguous when two types share a common field name, but it's easy enough to force those to be custom-resolved.
func (r babySleepResolver) DurationTxt(ctx context.Context, obj models.BabySleep) (string, error) {
return "duration", nil
}
