Skip to content
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

[Post!]! becomes []*Post not []Post in 0.9.0 #715

Closed
ZackKorman opened this issue May 17, 2019 · 9 comments
Closed

[Post!]! becomes []*Post not []Post in 0.9.0 #715

ZackKorman opened this issue May 17, 2019 · 9 comments

Comments

@ZackKorman
Copy link

What happened?

Generate is turning the following schema:

type Post {
        id: Int!
}

type Article {
	posts: [Post!]!
}

into:

type Post struct {
        ID         int        `json:"id"`
}

type Article {
	 Posts         []*Post        `json:"posts"`
}

What did you expect?

I expected the following generated types, which has been the case with previous versions:

type Post struct {
        ID         int        `json:"id"`
}

type Article {
	 Posts         []Post        `json:"posts"`
}

That is, I expected [Post!]! to become []Post not []*Post. I cannot tell whether this is intentional, based on #710 and #711, or not.

Minimal graphql.schema and models to reproduce

See above.

versions

  • gqlgen version? 0.9.0
  • go version? 1.12.0
  • dep or go modules? go modules
@vektah
Copy link
Collaborator

vektah commented May 18, 2019

This was intentional, see #710

It makes gqlgen more consistent with other codegen tools like prisma and protobuffer and generally reduces boilerplate.

See also #375 (comment)

@ZackKorman
Copy link
Author

ZackKorman commented May 18, 2019

Ahh, I didn't see #375. Alright. This requires a huge refactor for us, but I'll live. Thanks.

@gissleh
Copy link
Contributor

gissleh commented May 18, 2019

I've discussed this in the Gitter and plan to make a PR about making this specific instance of pointer-slices being used instead of struct-value-slices a configuration choice.

@vektah vektah reopened this May 18, 2019
@mtibben
Copy link
Member

mtibben commented May 19, 2019

a configuration choice

Seems this would add considerable complexity, without much upside. What's the rationale?

@gissleh
Copy link
Contributor

gissleh commented May 19, 2019

I've used gqlgen since 0.5, and while the refactor for 0.8 was mostly done by search-replace and about 1 block of boilerplate per model, refactoring only the resolvers for this one would mean a lot of loops to convert between. I can understand the rationale for pointers to single structs due to compilation errors, but struct-of-slice-pointers seems to be a choice mentioned in a single comment and then accepted.

I'll post the PR and let you review it. If the added complexity isn't worth it, feel free to reject it.

@Daavidaviid
Copy link

Yeah me too, seems kind of complicated to solve this.

@PianoOrDota2
Copy link

this break the spec of graphql, which define the syntax of "!", what the plan or what this tool will be.

@mathewbyrne
Copy link
Contributor

This is an intentional change in 0.9 and brings slices in line with regular struct resolvers. Further discussion in #719

this break the spec of graphql, which define the syntax of "!", what the plan or what this tool will be.

I'm not sure what you mean here. This issue is about the return type from a resolver, and has no bearing on the GraphQL spec.

@malekjaroslav
Copy link

malekjaroslav commented Jun 8, 2019

This was intentional, see #710

It makes gqlgen more consistent with other codegen tools like prisma and protobuffer and generally reduces boilerplate.

See also #375 (comment)

@vektah I am using Prisma and the methods always return a slice of structs, not pointers, so I have to retype it every time, or am I doing something wrong? My issue: (#738)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants