-
Notifications
You must be signed in to change notification settings - Fork 493
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
Separate resolvers for queries and mutations #182
Conversation
3ac05e2
to
df9ba5a
Compare
What happened? |
This change will break compatibility and many people will have to rewrite their code. |
@sanae10001 are you still working within @GhostRussia there may be some way that we can provide the new functionality without breaking clients (i.e. via some option or some temporary cleverness in the resolver lookup code). Either way, we'll want to ensure we communicate the changes and impact of the changes before merging this in. |
I think can use the interface to determine the type of resolver. type Queryer interface {
Query() interface{}
}
type Mutationer interface {
Mutation() interface{}
} And when using interfaces, we do not have to do extra reflection. rFunc := root.MethodByName("Query")
if !rFunc.IsValid() {
return nil, errors.New("not found query resolver")
}
queryResolver = rFunc.Call(nil)[0] use: type RootResolver struct {
}
func (r *Resolver) Query() interface{} {
return &QueryResolver{}
}
func (r *Resolver) Mutation() interface{} {
return &MutationResolver{}
}
graphql.MustParseSchema(schema, &RootResolver), I checked here, this code allows working with two versions of resolvers. Original tests pass, but other tests are needed. full resolvers patch: Adapted tests patch: and pass test https://github.com/graph-gophers/graphql-go/pull/182/files#diff-3a3269459d813f994deb0997a653aac2 - func (r *RootResolver) Query() *QueryResolver {
+ func (r *RootResolver) Query() interface{} {
return &QueryResolver{}
}
- func (r *RootResolver) Mutation() *MutationResolver {
+ func (r *RootResolver) Mutation() interface{} {
return &MutationResolver{}
} |
#182 (comment) |
Looks like we had two webhooks to the SemaphoreCI integration that were racing each other. I removed the old one that pointed to the previous repository, so we shouldn't see these issues. |
Hi there, Is there any ETA regarding this PR? Thanks a lot for your contribution. |
affd1aa
to
ffadb9b
Compare
@mytototo Now, it don't break compatibility. All above codes can correctly run. Maybe more tests are needed. |
@sanae10001 Ok, thanks a lot. |
Any plan on merging this? |
Do you need any help with this PR to get it merged? @pavelnikolov |
ffadb9b
to
8996c33
Compare
I'm trying to respond promptly to all new issues and PRs. I'm sorry for the delay on existing PRs. I'll review shortly. |
I wonder if this can be done in a way that doesn't introduce a breaking change 🤔 |
It don't break compatibility. All above codes can correctly run. |
BTW, what about implementing Go modules? This way we can introduce breaking
changes with time when a gain is found.
…On Fri, Nov 16, 2018, 6:07 AM Yingjie ***@***.***> wrote:
I wonder if this can be done in a way that doesn't introduce a breaking
change 🤔
It don't break compatibility. All above codes can correctly run.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#182 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AH9dxrjxYgI2R__A584-IDJ5tOO0i1XNks5uvivZgaJpZM4SroNG>
.
|
This is not completely true. You had to change the Star Wars example, right? This means that all users of the library will have to do the same when they switch to the latest version. It's not optional. It forces the users to upgrade. |
Maybe it's a good idea. This in turn, would also increase complexity. I don't want to introduce something without a clear problem that it solves. This is a very dangerous path that can lead to a lot of unnecessary complexity with very little ROI. |
a34aa17
to
e98d8f1
Compare
e98d8f1
to
1e4bb14
Compare
@pavelnikolov |
@pavelnikolov I'm wondering what the state of this ticket is. As @sanae10001 mentioned, the PR has code to determine if the resolvers are separated or not, and falls back on the existing behavior. |
@johnmaguire it is not currently being worked on, as far as I know. |
See #421 for a workaround for that, we use this PR in production code, all our resolver's name are prefixed with either |
Excuse my ignorance @pavelnikolov but my impression was that this PR was ready for review but has since generated merge conflicts. Is there a reason it wasn't merged in 2018? Would it be merged if it were cleaned up today? It's worth noting that the gqlgen feature comparsion page points to this issue as a point of distinction for their project. |
@sanae10001 I started working on this and will try to add it to the next release. I like your code and I will copy some portion of it. |
Closing this in favor of #561 |
See #145