Това вероятно заслужава пълно обяснение за тези, които биха могли да търсят това, така че добавяне на едно за бъдещите поколения.
По-конкретно това, което се връща, е поток от събития за node.js, който ефективно обвива stream.Readable интерфейс с няколко удобни метода. A .count() не е един от тях в момента и като се има предвид текущият използван интерфейс, няма да има много смисъл.
Подобно на резултата, върнат от .stream()
метод, достъпен за обектите на курсора, "броене" няма да има много смисъл тук, когато вземете предвид реализацията, тъй като е предназначено да обработва като "поток", където в крайна сметка ще стигнете до "край", но иначе просто искате да обработите докато стигнем там.
Ако сте обмислили стандартния интерфейс „Курсор“ от драйвера, има някои солидни причини, поради които курсорът за агрегиране не е същият:
-
Курсорите позволяват действията "модификатор" да бъдат обработени преди изпълнението. Те попадат в категориите на
.sort(),.limit()и.skip(). Всички те всъщност имат аналогични директиви в рамката за агрегиране, които са посочени в процеса. Като етапи на конвейер, които могат да се появят „навсякъде“, а не само като опция за последваща обработка на проста заявка, няма да има много смисъл да се предлага същата обработка на „курсор“. -
Други модификатори на курсора включват специални като
.hint(),.min()и.max()които са промени в "избора на индекс" и обработката. Въпреки че те могат да бъдат полезни за тръбопровода за агрегиране, в момента няма прост начин да ги включите в избора на заявки. Най-вече логиката от предишната точка отменя всяка точка на използване на същия тип интерфейс за „Курсор“.
Другите съображения са какво всъщност искате да правите с курсора и защо "искате" да бъде върнат. Тъй като курсорът обикновено е „еднопосочно пътуване“ в смисъл, че те обикновено се обработват само докато се достигне край и в използваеми „партиди“, тогава се прави разумно заключение, че „броенето“ всъщност идва в края, когато всъщност тази "опашка" най-накрая е изчерпана.
Въпреки че е вярно, че всъщност стандартната реализация на „курсор“ съдържа някои трикове, основната причина е, че това просто разширява концепцията за „мета“ данни, тъй като машината за профилиране на заявки трябва да „сканира“ определен брой документи, за да определи кой елементи за връщане в резултата.
Рамката за агрегиране обаче играе малко с тази концепция. Тъй като не само има същите резултати, каквито биха били обработени чрез стандартния инструмент за профилиране на заявки, но има и допълнителни етапи. Всеки от тези етапи има потенциала да „модифицира“ получения „брой“, който действително ще бъде върнат в „потока“, за да бъде обработен.
Отново, ако искате да погледнете това от академична гледна точка и кажете, че „Разбира се, машината за заявки трябва да запази „мета данните“ за преброяването, но можем ли да не проследим какво се променя след това?“. Това би бил справедлив аргумент и тръбопроводните оператори като $match
и $group
или $unwind
и евентуално дори включително $project
и новия $redact
, всички те могат да се считат за разумен случай за поддържане на собствена следа на „обработените документи“ във всеки етап на конвейера и актуализиране на това в „мета данните“, които евентуално биха могли да бъдат върнати, за да обяснят пълния брой резултати от конвейера.
Последният аргумент е разумен, но помислете също така, че в момента внедряването на концепция „Курсор“ за резултатите от конвейера за агрегиране е нова концепция за MongoDB. Може да се твърди, че всички „разумни“ очаквания в първата точка на проектиране биха били, че „повечето“ резултати от комбинирането на документи няма да са с размер, който е ограничителен за ограниченията на BSON. Но с разширяването на употребата тогава възприятията се променят и нещата се променят, за да се адаптират.
Така че това „може“ евентуално да бъде променено, но не е начинът, по който се прилага „в момента“. Докато .count() при стандартна реализация на курсора има достъп до „мета данните“, където се записва сканираният номер, всеки метод на текущата реализация би довел до извличане на всички резултати от курсора, точно както .itcount() прави в обвивката.
Обработете елементите „курсор“, като разчитате на събитието „данни“ и излъчвате нещо (вероятно генератор на JSON поток) като „броене“ в края. За всеки случай на употреба, който би изисквал преброяване „предварително“, така или иначе няма да изглежда като валидна употреба за курсор, тъй като със сигурност резултатът ще бъде цял документ с разумен размер.
