-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Config option to only make cyclical struct fields pointers #2174
Config option to only make cyclical struct fields pointers #2174
Conversation
133f106
to
ae1d2e4
Compare
Need to update docs and examples, but is this change okay otherwise? @StevenACoffman This will be a breaking change for any users of gqlgen whose schemas include non-cyclical struct fields (see my example of this above), as this change alters the generated structs in that case. To make this less bad, we could make this behavior non-default using a config option, but I do think this should be the default behavior, as it is what a developer would expect to happen, in my opinion. That said, the slice pointer thing is also behind a config option and does not behave the way I would expect by default, so this would not be the only time where something unexpected happens that requires changing the config. |
So this will cause a lot of churn for existing users if they don't specifically opt-in, so I'd ideally like this changed behavior to be a config option if possible. |
ae1d2e4
to
480886c
Compare
480886c
to
6ad563d
Compare
I added a config option for this which defaults to gqlgen's behavior today without this PR, so that it doesn't affect any users unless they explicitly opt in to the new behavior using the config option. I also added tests that validate the old behavior and the new behavior, and added the new config option to the config doc page. The examples did not need to be changed since the default behavior of gqlgen has not changed. |
Can you clarify what you mean by "default to old behavior"? Before PR #701 was merged is one "old behavior", and before this PR is merged is a different "old behavior"? |
Woops, to clarify, "old behavior" is the behavior of gqlgen today without my PR. New behavior is the behavior with this PR.
gqlgen, with my PR, will still default to the same behavior as today. The behavior will only change if you add `struct_fields_always_pointers: false` to your config. The default value for that option is `true`
|
6ad563d
to
e15da34
Compare
Fixed the golangci-lint issue... |
This PR #701 caused all struct fields whose type is a struct to be generated as pointers. This was necessary to resolve issues with cyclical relationships between structs (e.g. StructA contains a field of type StructB and vice versa) because those will cause compiler errors.
However this was overkill and also caused non-cyclical struct relationships to turn into pointers. For example:
...would unnecessarily generate
StructB.field_two
with the type*StructA
instead of justStructA
.This PR adds a config option that allows a user to retain the pointer change from the linked PR for cyclical relationships, but otherwise gqlgen will not change the type to a pointer for cases like the example I gave above.
The default behavior of gqlgen remains the same, so this will not affect any existing users unless they add
struct_fields_always_pointers: false
to their config.Examples of behavior with this PR, using
struct_fields_always_pointers: false
:I have: