You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have a graphql schema like this:
D has many S has many SW has one W has many C.
D is available via a root level query.
(The underlying SQL has the same set of entities and relationships between them).
Using apollo server (not sure if relevant), postgres and knex.
I started by adding a dataloader for C. I then made a root level query for D, asking for all the properties of each element in the above schema. Testing revealed that the caching worked - each distinct C was only queried for once. But batching didn't work - for each distinct C, there was a separate SELECT.
When debugging this, added batchScheduleFn: (callback) => setTimeout(callback, 100) to the dataloader for C. At that point, batching started to work.
This made me think that somehow the C resolution was taking place on different event loop tics. On a hunch, I added a dataloader for W, SW and S. (none for D, as there is just one root level query for D).
After doing this, batching worked for all of S, SW, W and C - even with the batchSchedule function removed.
So I wanted to ask - is this possibly a bug (either in dataloader or, for a separate matter, Apollo Server), or is it expected that batching at the leaf node C would not work unless all ancestor nodes are also resolved with dataloaders?
If this isn't a bug, I wonder if adding this information to the documentation would be possible, to help other people who find themselves in this situation - implementing dataloader only at the leaf of a deep schema, and having batching not work they way they expected it would?
Anyhow, thanks for the library and its ongoing maintenance :)
The text was updated successfully, but these errors were encountered:
Hi there,
I have a graphql schema like this:
D has many S has many SW has one W has many C.
D is available via a root level query.
(The underlying SQL has the same set of entities and relationships between them).
Using apollo server (not sure if relevant), postgres and knex.
I started by adding a dataloader for C. I then made a root level query for D, asking for all the properties of each element in the above schema. Testing revealed that the caching worked - each distinct C was only queried for once. But batching didn't work - for each distinct C, there was a separate SELECT.
When debugging this, added batchScheduleFn: (callback) => setTimeout(callback, 100) to the dataloader for C. At that point, batching started to work.
This made me think that somehow the C resolution was taking place on different event loop tics. On a hunch, I added a dataloader for W, SW and S. (none for D, as there is just one root level query for D).
After doing this, batching worked for all of S, SW, W and C - even with the batchSchedule function removed.
So I wanted to ask - is this possibly a bug (either in dataloader or, for a separate matter, Apollo Server), or is it expected that batching at the leaf node C would not work unless all ancestor nodes are also resolved with dataloaders?
If this isn't a bug, I wonder if adding this information to the documentation would be possible, to help other people who find themselves in this situation - implementing dataloader only at the leaf of a deep schema, and having batching not work they way they expected it would?
Anyhow, thanks for the library and its ongoing maintenance :)
The text was updated successfully, but these errors were encountered: