Gqlgen: `[Post!]!` becomes `[]*Post` not `[]Post` in 0.9.0

Created on 17 May 2019  路  9Comments  路  Source: 99designs/gqlgen

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

Most helpful comment

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.

All 9 comments

This was intentional, see https://github.com/99designs/gqlgen/pull/710

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

See also https://github.com/99designs/gqlgen/issues/375#issuecomment-480779700

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

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.

a configuration choice

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

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.

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

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

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.

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: (https://github.com/99designs/gqlgen/issues/738)

Was this page helpful?
0 / 5 - 0 ratings

Related issues

cajax picture cajax  路  4Comments

coderste picture coderste  路  3Comments

sumanthakannantha picture sumanthakannantha  路  3Comments

bjm88 picture bjm88  路  4Comments

msmedes picture msmedes  路  4Comments