DataLoader does not de-dupe keys when not configured to cache.
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 3/5
- Thời gian dự kiến
- 1-2 ngày
- Mức phù hợp với người mới
- 48/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Đình trệ
- Công nghệ
- javascript, node.js
- Lĩnh vực
- backend
Hướng nghiên cứu
Bắt đầu từ quá trình khởi tạo DataLoader với cache: false và theo dõi load(1) qua việc dispatch theo batch và ánh xạ kết quả. Thêm một regression test cho thấy các key lặp lại được truyền duy nhất vào batch function, trong khi mỗi request vẫn nhận được kết quả của mình; issue hoàn tất khi hành vi này hoạt động mà không có bộ nhớ đệm trong memory.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Expected Behavior
If I pass in multiple identical keys, then the batch function should only be called with the unique set of keys, even if not caching (they are still identical requests.)
Current Behavior
The data loader does not de-duplicate the keys and they are passed along in full to the batch function,.
Possible Solution
The data loader should still de-duplicate the keys. My understanding of "cache" is about whether the results are kept in memory after the batch function is called, not whether or not they are batched up. So I would expect that the data loader would still keep map the unique set of results back to each request which asked for those keys.
Steps to Reproduce
Create a DataLoader with {cache: false} as the options.
Call load(1) twice.
Let the batch function get called.
Note that the value 1 will be present twice in the keys.
Context
We have designed our batch functions to expect each key only once, since that is what the data loader supplies in "normal" cases (normal = cache: true). However, we have recently written a thin wrapper around a data loader, which actually delegates the caching part to Redis so we can get caching across processes / machines. Note that Redis is the backing store for the cache, it is NOT the place the real batch function goes to get data.
As such we just wrap a DataLoader with a simple class that takes the options and the actual batch function, and stores those, but create a data loader inside the object with whatever the supplied data loader options were, but with cache: false. This data loader is given a batch function which is just a closure function which will then go and look things up in Redis and only call the underlying real batch function with the set of keys which are not in the cache.
We can turn this on and off as for our local developers there was no need to force them to spin up a Redis instance, so our code can configurable instantiate a native DataLoader or a CachingDataLoader. We noticed we got some very odd behaviour only when using the caching data loader and after investigation we discovered that this was because our caching data loader batch function was receiving duplicate keys. We were merrily passing these on to our underlying real batch function when there was a cache miss as we assumed they were unique. Our batch functions were all written when we weren't using this and hence they had never been tested with duplicate keys. Granted perhaps we should have tested them but we didn't because at the time it seemed it could never happen.
We have written some code in our caching data loader batch function which de-dupes the list, but semantically it felt wrong that the data loader would not de-dupe the list when it was not caching the results in memory. It felt like the logic of taking in multiple requests across a set of (sometimes repeating) keys and then farming out the responses from the batch function to those requests, should be orthogonal to whether or not those responses were held in memory afterwards or not. Hence the "bug." Perhaps this is a feature request, not entirely sure but it felt disconnected enough from expected behaviour that I've opted to file it as a bug for now. :)
- Ngôn ngữ chính
- JavaScript
- Star
- 13.4k
- Fork
- 522
- Chỉ số merge pull request
- Không có pull request nào được merge trong 30 ngày
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Không có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của graphql/dataloader
-
[BUG] `maxBatchSize: NaN` is accepted and silently disables batchingCó thể đã có người làm @RaphaelFakhri đã nhận 2 ngày trước. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
graphql/dataloader#405 ·
-
Failed batch evicts a replacement cache entry after clear/primeCó thể đã có người làm @Claire-ovo đã nhận 11 ngày trước. Đang mở
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 57/100
graphql/dataloader#403 ·
-
enhancement
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 38/100
graphql/dataloader#393 ·
-
enhancement
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 25/100
graphql/dataloader#382 ·
-
enhancement
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 35/100
graphql/dataloader#379 · 2 bình luận · 5 reaction ·
Tất cả issue của graphql/dataloader
Issue tương tự
-
binding:python bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
Maintainer thường phản hồi trong vòng 1 ngày
-
bug needs-triage potential-regression
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
aws/aws-sdk-js-v3#8408 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
[v3] KeyBindingManager calls (Add/Remove) are not converted into a case-insensitive accelerator.KeyĐang mởBug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
Maintainer thường phản hồi trong vòng 4 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100