Detta förtjänar möjligen en fullständig förklaring för dem som kanske söker efter detta, så lägg till en för eftervärlden.
Specifikt vad som returneras är en händelseström för node.js som effektivt omsluter strömmen.Läsbar gränssnitt med ett par bekvämlighetsmetoder. En .count() är inte en av dem för närvarande och med tanke på det nuvarande gränssnittet som används skulle det inte vara mycket meningsfullt.
Liknar resultatet som returneras från .stream()
metod som är tillgänglig för markörobjekt, skulle en "räkning" inte vara så meningsfull här när du tänker på implementeringen, eftersom den är tänkt att bearbeta som en "ström" där du så småningom kommer att nå ett "slut" men annars bara vill bearbeta tills du kommer dit.
Om du övervägde standardgränssnittet "Markör" från drivrutinen, finns det några solida skäl till varför aggregeringsmarkören inte är densamma:
-
Markörer tillåter att "modifierare"-åtgärder bearbetas innan de körs. Dessa faller inom kategorierna
.sort(),.limit()och.skip(). Alla dessa har faktiskt motpartsdirektiv i aggregeringsramverket som specificeras i pipelinen. Som pipeline-steg som kan visas "var som helst" och inte bara som ett efterbearbetningsalternativ för en enkel fråga, skulle det inte vara så meningsfullt att erbjuda samma "markör"-behandling. -
Andra markörmodifierare inkluderar specialiteter som
.hint(),.min()och.max()som är ändringar av "indexval" och bearbetning. Även om dessa kan vara användbara för aggregeringspipelinen, finns det för närvarande inget enkelt sätt att inkludera dessa i frågeval. För det mesta åsidosätter logiken från föregående punkt varje punkt med att använda samma typ av gränssnitt för en "markör".
De andra övervägandena är vad du faktiskt vill göra med en markör och varför du "vill" ha en tillbaka. Eftersom en markör vanligtvis är en "envägsresa" i den meningen att de vanligtvis bara bearbetas tills ett slut nås och i användbara "batcher", så drar den en rimlig slutsats att "räkningen" bara kommer i slutet, när faktiskt den "kön" äntligen är uttömd.
Även om det är sant att standardimplementeringen av "markören" faktiskt innehåller några knep, är huvudskälet att detta bara utökar ett "meta" datakoncept eftersom frågeprofileringsmotorn måste "skanna" ett visst antal dokument för att avgöra vilket objekt att returnera i resultatet.
Aggregeringsramverket leker dock lite med detta koncept. Eftersom det inte bara finns samma resultat som skulle bearbetas genom standardfrågeprofileraren, utan det finns även ytterligare steg. Alla dessa steg har potential att "modifiera" det resulterande "antal" som faktiskt skulle returneras i "flödet" för att bearbetas.
Återigen, om du vill titta på detta från en akademisk synvinkel och säga att "Visst, frågemotorn ska behålla 'metadata' för räkningen, men kan vi inte spåra vad som ändras efter?". Detta skulle vara ett rättvist argument, och pipelineoperatörer som $match
och $group
eller $unwind
och möjligen även inklusive $project
och den nya $redact
, alla skulle kunna betraktas som ett rimligt fall för att hålla sin egen koll på de "behandlade dokumenten" i varje steg i pipeline och uppdatera dessa i "metadata" som eventuellt skulle kunna returneras för att förklara hela antalet pipelineresultat.
Det sista argumentet är rimligt, men tänk också på att implementeringen av ett "Cursor"-koncept för aggregeringspipelineresultaten för närvarande är ett nytt koncept för MongoDB. Det kan på ett rättvist sätt hävdas att alla "rimliga" förväntningar vid den första designpunkten skulle ha varit att "de flesta" resultat från att kombinera dokument inte skulle vara av en storlek som var begränsande för BSON-begränsningarna. Men när användningen ökar ändras uppfattningarna och saker och ting förändras för att anpassa sig.
Så detta "kan" möjligen ändras, men det är inte hur det "för närvarande" implementeras. Medan .count() på en standardmarkörimplementering har tillgång till "metadata" där det skannade numret registreras, skulle vilken metod som helst på den aktuella implementeringen resultera i att alla markörresultat hämtas, precis som .itcount() gör i skalet.
Bearbeta "markör"-objekten genom att räkna med "data"-händelsen och sända ut något (möjligen en JSON-strömgenerator) som "count" i slutet. För alla användningsfall som skulle kräva en räkning "i förväg" verkar det inte som en giltig användning av en markör i alla fall, eftersom utdatan skulle vara ett helt dokument av rimlig storlek.