… #436
… #436
Conversation
…luginsForSchemaResolvers function, #3988) so "!field.resolve" is not a good check for columns. Using parentTypeNode.constructor.name === 'GraphQLObjectType'
| // is it just a column? if they specified a sqlColumn or they didn't define a resolver, yeah | ||
| } else if (fieldConfig.sqlColumn || !field.resolve) { | ||
| // or maybe it just depends on some SQL columns | ||
| } else if (fieldConfig.sqlDeps) { |
There was a problem hiding this comment.
Because fieldConfig.sqlDeps usually has field.resolve set and didn't match fieldConfig.sqlColumn || !field.resolve condition.
Now field.resolve is always set so fieldConfig.sqlDeps need higher priority.
|
Would you mind cleaning up your commit message? If you need more than can fit on one line, then do |
|
@alexbbt I found cases where my solution didn't works as expected so I need to fix it (see failed test).
should be marked with "ignoreAll: true" because join-monster has nothing to do. |
|
Ah got it, a draft was a good start. Yes I think |
|
Any progress on this? I just upgraded to join-monster v3 from v2, and I was able to get everything working with |
|
I've created a new PR with minor adjustments to this code and passing tests here #444 . I believe it is ready to merge in its current state, waiting on review. |
|
Closing in favor of the new PR |
Using recent apollo-server-core populateASTNode(..) don't detect most columns if sqlColumn is not set.
Digging I found that recent apollo-server-core always define a field resolver (see
#3988 enablePluginsForSchemaResolvers() function
) so "!field.resolve" is not a good check for columns.
I found using parentTypeNode.constructor.name === 'GraphQLObjectType' is correct in all cases I can test.