Prisma1: Fragments in Go client

[divyenduz]

Is your feature request related to a problem? Please describe.
Currently, the go client does not have the JS based client equivalent of $fragment syntax. This leads to inconvenience in data access as described here: https://github.com/prisma/prisma-examples/issues/142

Describe the solution you'd like
To add fragment feature to the Go client, we can add 2nd parameter to the Exec function as following:-

1. Approach, add arguments to Exec

users []User
client.Users().Exec(ctx, "fragment u on User { id }", &users)

1. Append fragment function in place of Exec

users []User
client.Users().Fragment(ctx, "fragment u on User { id }", &users)

These could be a few approaches. We can also think about other ideas. Broadly, we need to specify the selection set after instructions are collected in place of choosing the scalars and duck type the response.

Describe alternatives you've considered
Current workaround is to do multiple operations via client i.e. run multiple queries to get the same result.

Additional context
https://github.com/prisma/prisma-examples/issues/142

[sachaarbonel]

Personaly speaking, I find the second approach much more elegant than the first one

[patrickdevivo]

I think I like the second option best, it seems like a good idea to be explicit about when the Fragment API is used, and "overloading" Exec might lead to situations where the user is passing in "" to _not_ use the fragment API

Excited for this implementation! But how would this work for relations? Could something like:

users []User
client.Users().Fragment(ctx, "fragment u on User { posts { id, title } }", &users)

be possible? And then how would the User struct gain Posts?

[schickling]

I agree, option 2 seems to be the way to go. Another suggestion could be:

users []CustomUserType
client.Users().Fragment("fragment u on User { id }").Exec(ctx, &users)

Note that users []User probably doesn't make sense in most cases and you'd want to define a custom, fragment/query-specific type.

[dominikh]

I'm leaning towards @schickling's suggestion; it seems the most consistent, and would theoretically allow further operations to be applied after fragment but before executing the query.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 10 days if no further activity occurs. Thank you for your contributions.