Using dataloader at leaf level of multi layer schema failed to batch
まだ誰も着手していません。
評価
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 初心者へのやさしさ
- 25/100
- issue の種類
- バグ
- 明瞭さ
- 説明が足りない
- 活発さ
- 停滞
- 技術スタック
- graphql, javascript, postgres
調査の方向性
まず、説明されている Apollo Server、Postgres、Knex のセットアップを使い、リーフレベル C にのみ DataLoader を適用して D→S→SW→W→C クエリを再現します。batchScheduleFn の有無でバッチ処理を比較し、その後 W、SW、S の祖先ローダーを追加します。完了の条件は、その挙動が想定どおりなのか DataLoader のバグなのかを判断し、適切であれば結論を文書化することです。
索引モデルが issue の本文から書いたものです。
説明
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 :)
- 主要言語
- JavaScript
- スター
- 13.4k
- フォーク
- 522
- PR マージ指標
- 30日以内にマージされた PR はありません
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートなし
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
graphql/dataloader のほかの issue
-
[BUG] `maxBatchSize: NaN` is accepted and silently disables batching対応中かも @RaphaelFakhri が 2 日前に担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
graphql/dataloader#405 ·
-
Failed batch evicts a replacement cache entry after clear/prime対応中かも @Claire-ovo が 11 日前に担当しました。 オープン
難易度 4/5 3〜5日 初心者へのやさしさ 57/100
graphql/dataloader#403 ·
-
enhancement
難易度 5/5 1週間以上 初心者へのやさしさ 38/100
graphql/dataloader#393 ·
-
enhancement
難易度 5/5 1週間以上 初心者へのやさしさ 25/100
graphql/dataloader#382 ·
-
enhancement
難易度 4/5 3〜5日 初心者へのやさしさ 35/100
graphql/dataloader#379 · コメント 2 件 · リアクション 5 件 ·
graphql/dataloader の issue をすべて見る
似ている issue
-
binding:python bug
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
メンテナーはふだん 1 日以内に返信
-
bug needs-triage potential-regression
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
aws/aws-sdk-js-v3#8408 ·
メンテナーはふだん 1 日以内に返信
-
[v3] KeyBindingManager calls (Add/Remove) are not converted into a case-insensitive accelerator.KeyオープンBug
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
メンテナーはふだん 4 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100