Điều này có thể xứng đáng được giải thích đầy đủ cho những người có thể tìm kiếm điều này, vì vậy hãy thêm một lời giải thích cho hậu thế.
Cụ thể, những gì được trả về là Luồng sự kiện cho node.js. Luồng này bao bọc hiệu quả luồng.Readable giao diện với một số phương pháp tiện lợi. Một .count() hiện tại không phải là một trong số chúng và việc xem xét giao diện hiện tại được sử dụng sẽ không có nhiều ý nghĩa.
Tương tự với kết quả được trả về từ .stream()
phương thức có sẵn cho các đối tượng con trỏ, "số lượng" sẽ không có nhiều ý nghĩa ở đây khi bạn xem xét việc triển khai, vì nó có nghĩa là xử lý như một "luồng" nơi cuối cùng bạn sẽ đạt đến "kết thúc" nhưng nếu không, bạn chỉ muốn xử lý cho đến khi đến đó.
Nếu bạn coi giao diện "Con trỏ" chuẩn từ trình điều khiển, có một số lý do chắc chắn khiến con trỏ tổng hợp không giống nhau:
-
Con trỏ cho phép các hành động "sửa đổi" được xử lý trước khi thực thi. Chúng thuộc các loại
.sort(),.limit()và.skip(). Tất cả những điều này thực sự có các chỉ thị đối ứng trong khuôn khổ tổng hợp được chỉ định trong đường ống. Vì các giai đoạn đường ống có thể xuất hiện "ở bất kỳ đâu" chứ không chỉ là một tùy chọn xử lý hậu kỳ cho một truy vấn đơn giản, điều này sẽ không có ý nghĩa gì nếu cung cấp cùng một quy trình xử lý "con trỏ". -
Các công cụ sửa đổi con trỏ khác bao gồm các từ đặc biệt như
.hint(),.min()và.max()là những thay đổi đối với "lựa chọn chỉ mục" và xử lý. Mặc dù chúng có thể được sử dụng cho đường ống tổng hợp, nhưng hiện tại không có cách đơn giản nào để đưa chúng vào lựa chọn truy vấn. Hầu hết logic từ điểm trước sẽ ghi đè bất kỳ điểm nào của việc sử dụng cùng một loại giao diện cho "Con trỏ".
Các cân nhắc khác là những gì bạn thực sự muốn làm với một con trỏ và tại sao bạn "muốn" một con trỏ được trả về. Vì con trỏ thường là "chuyến đi một chiều" theo nghĩa là chúng thường chỉ được xử lý cho đến khi đạt được kết thúc và trong "lô" có thể sử dụng được, do đó, nó đưa ra kết luận hợp lý rằng "số lượng" chỉ thực sự đến ở cuối, thực tế là "hàng đợi" cuối cùng đã cạn.
Mặc dù đúng là trên thực tế, việc triển khai "con trỏ" tiêu chuẩn có một số thủ thuật, lý do chính là điều này chỉ mở rộng khái niệm dữ liệu "meta" vì công cụ lập hồ sơ truy vấn phải "quét" một số tài liệu nhất định để xác định tài liệu nào các mục để trả về trong kết quả.
Mặc dù vậy, khuôn khổ tổng hợp chơi với khái niệm này. Vì không chỉ có các kết quả giống như sẽ được xử lý thông qua trình mô tả truy vấn tiêu chuẩn, mà còn có các giai đoạn bổ sung. Bất kỳ giai đoạn nào trong số này đều có khả năng "sửa đổi" "số lượng" kết quả thực sự sẽ được trả lại trong "luồng" sẽ được xử lý.
Một lần nữa, nếu bạn muốn xem xét điều này từ quan điểm học thuật và nói rằng "Chắc chắn, công cụ truy vấn nên giữ 'dữ liệu meta' cho số lượng, nhưng chúng tôi có thể không theo dõi những gì được sửa đổi sau đó không?". Đây sẽ là một lập luận công bằng và các nhà khai thác đường ống như $match
và $group
hoặc $unwind
và thậm chí có thể bao gồm cả $project
và $redact mới
, tất cả đều có thể được coi là một trường hợp hợp lý để theo dõi riêng của họ về "tài liệu được xử lý" trong từng giai đoạn quy trình và cập nhật dữ liệu đó trong "dữ liệu meta" có thể được trả lại để giải thích số lượng kết quả toàn tuyến.
Lập luận cuối cùng là hợp lý, nhưng cũng nên xem xét rằng tại thời điểm hiện tại việc triển khai khái niệm "Con trỏ" cho kết quả đường ống tổng hợp là một khái niệm mới đối với MongoDB. Có thể lập luận một cách công bằng rằng tất cả các kỳ vọng "hợp lý" ở điểm thiết kế đầu tiên sẽ là "hầu hết" kết quả từ việc kết hợp các tài liệu sẽ không có kích thước hạn chế đối với các giới hạn của BSON. Nhưng khi việc sử dụng mở rộng thì nhận thức được thay đổi và mọi thứ thay đổi để thích ứng.
Vì vậy, "có thể" này có thể được thay đổi, nhưng nó không phải là cách nó được thực hiện "hiện tại". Trong khi .count() trên triển khai con trỏ tiêu chuẩn có quyền truy cập vào "siêu dữ liệu" nơi số được quét được ghi lại, bất kỳ phương pháp nào trên triển khai hiện tại sẽ dẫn đến việc truy xuất tất cả các kết quả con trỏ, giống như .itcount() trong shell.
Xử lý các mục "con trỏ" bằng cách đếm sự kiện "dữ liệu" và đưa ra một thứ gì đó (có thể là trình tạo luồng JSON) làm "số lượng" ở cuối. Đối với bất kỳ trường hợp sử dụng nào yêu cầu số lượng "lên trước", dù sao thì nó sẽ không phải là cách sử dụng hợp lệ cho con trỏ, vì chắc chắn kết quả đầu ra sẽ là toàn bộ tài liệu có kích thước hợp lý.
