Relationships missing in virtual resolver callback
See original GitHub issueBug report
Describe the bug
I’m not able to access fields of relationship type in virtual field resolver method.
To Reproduce
Create model with relationship field of type many
and virtual field that should return number of relationships. But object item.answers
is undefined
.
fields: {
question: {
type: Text,
isRequired: true,
},
stats: {
type: Virtual,
resolver: (item) => item.answers.length,
},
answers: {
type: Relationship,
many: true,
ref: 'PollAnswer',
},
},
If I print content of item
object I get only:
{ question: 'New on', __v: 0, id: '5e3179fcf456f0b86ae2dab8' }
System information
- OS: macOS
Issue Analytics
- State:
- Created 4 years ago
- Comments:6 (6 by maintainers)
Top Results From Across the Web
Configure callback behavior for VA IVR
Configure the behavior of the automated customer callbacks, such as number of attempts and time between the calls, tried by the user.
Read more >Plugins - esbuild
Plugins. The plugin API allows you to inject code into various parts of the build process. Unlike the rest of the API, it's...
Read more >Amazon Cognito authentication issues with OpenSearch ...
This error occurs when you're missing the callback URL configuration in Amazon Cognito's app client settings. To check that your App client settings...
Read more >StoreFront 2203 LTSR – Configuration for Citrix Gateway
The Callback URL must resolve to any Citrix Gateway VIP on the same appliance that authenticated the user. Edit the HOSTS file on...
Read more >Web service error codes (Microsoft Dataverse) - Power Apps
Message: Configuration data missing for CDS ADLS service. ... Message: An N:N relationship between virtual entities is not supported.
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
This is actually the expected behaviour, although perhaps it’s not well documented. Within a virtual field resolver we don’t necessarily know which relationships the developer will need, nor how deeply nested they might need to access things. Also, an item might have millions of related items, and it would be particularly inefficient to immediately look all of these up if they’re not actually needed. As it is impossible to know, we resist the temptation to guess and simple provide the item as stored in the database (notice the
__v
field, which is a mongo thing). If you need to access the related items you will need to perform a subsequent graphql query and define the filters and returned fields on the item.Thanks for this answer Tim, I added this to the virtual field docs: https://github.com/keystonejs/keystone/blob/master/packages/fields/src/types/Virtual/README.md