Open sjhitchner opened 3 years ago
Maybe I should release the development version today it has a lot of bug fixes. Anyway the code you send should never be called since multiple schemas are not supported yet (but is there since I copied code).
I will release a new version today where the resolver and template code is simplified!
Awesome, looking forward to the updated version. I'll take a look through the code today and try to understand why it's entering the multiple schema block.
Also, I have one other question. It is possible to disable generating an edges/connections schema in v3? For my particular projects edges/connections add unneeded complexity. I took a look through the code but didn't see an obvious flag.
Thanks again!
It should be in gqlgen.yml, in the new version it does not look at this file but generates only 1 file for now.
@sjhitchner I think I'll keep the edges since we need them. I won't work on disabling this via a flag. But feel free to make a pull request which has a flag for this or something like that but be sure to make it for everything (the schema generator + resolver + converts)
Most of the time pagination is needed after a while in a project so I think it's good + it's fast with cursor-based pagination out of the box e.t.c.
Do you not need pagination or do you think the connections/edges are just too complex? ( I agree on that, but it has some reasons for that)
I forgot about this, I'll try to release tomorrow!
I definitely think pagination support is essential. The edges/connections model does provide that but with much more complex queries. I believe React/Relay requires edges/connections. But I've just used Apollo client so far which seems much simpler (I am NOT an expert with JS/React, so my opinions might be invalid).
I've added pagination in the past by adding limit
and from
parameters on the list
options. That seemed to work fine and give me the functionality I needed.
I can see the reason to conform to a more industry standard approach. I just was curious if library supported removing them.
Yeah to be honest with you I think the Relay specification is overengineered to handle very niche cases. But if you have them you can query the cursor on them. The arguments to the connections are simplified since relay does not support both forward and backward pagination as arguments.
So if you have first: 10, after: "sljdflksj==" it will use forward pagination and last:10 before: "slsl==" it will use backward pagination.
It implements the following spec: https://relay.dev/graphql/connections.htm
New version is released. Please follow upgrade notes and let me know if this fixed it for you.
cfg, err := config.LoadConfigFromDefaultLocations()
(convert_plugin.go) should be placed after if err := gbgen.SchemaWrite(gbgen.SchemaConfig{
Like in the updated README.md maybe this resulted in your error.
Awesome, thanks for the update. Definitely making some progress but I have encountered a few more issues I'm trying to sort out.
Missing imports:
.../helpers/convert.go
.../helpers/convert_input.go
.../helpers/filter.go
.../helpers/sort.go
../helpers/preload.go
Are missing the graphql model and db model import statements in my case:
gqlmodels github.com/sjhitchner/soapcalc/backend/generated/graphql/models"
dbmodels github.com/sjhitchner/soapcalc/backend/generated/db/models"
Also resolver.go needs to import the generated graphql code
// needs to import "gm github.com/sjhitchner/soapcalc/backend/generated/graphql"
func (r *Resolver) Mutation() fm.MutationResolver { return &mutationResolver{r} } // should be gm not fm
func (r *Resolver) Query() fm.QueryResolver { return &queryResolver{r} } // should be gm not fm
type mutationResolver struct{ *Resolver }
type queryResolver struct{ *Resolver }
I think this may be just be template issues.
Making the manual changes above I get everything to compile and runs!
I think this fixes the issues I was experiencing in the above post
The only issue I'm facing right now is that when I run the plugin go run convert_plugin.go
two resolver files are generated
resolver.go
schema.resolver.go
There are a number of errors about how various objects are defined twice and schema.resolver.go
is missing a number of imports.
If, after running the plugin, I delete schema.resolver.go
everything compiles.
Is it expected behaviour for both resolvers to be generated. If not, any ideas what I have misconfigured?
I think the gqlgen file should only contain this for the resolver key
resolver:
filename: resolver.go
type: Resolver
Hey, finally got time to come back to using gqlgen-sqlboiler.
I'm running into another issue.
Here is my convert_plugin.go
When I run it I get the following output/error
It seems strange to me that the
resolver
is using theconvert.gotpl
so I dug in a little further.This Render statement doesn't include a
Template
option is this ok? https://github.com/web-ridge/gqlgen-sqlboiler/blob/049ffb39018c5e0e866ae4ff8ec91f217f2a9268/resolver.go#L191Locally I modified that file to
When I run
convert_plugin.go
using the modified file I get the following outputIt looks like the template executes correctly but the resolver code generated are not valid Go.
Any ideas?