Dette fortjener muligvis en fuldstændig forklaring for dem, der måtte søge efter dette, så tilføj en for eftertiden.
Det, der specifikt returneres, er en begivenhedsstrøm til node.js, som effektivt omslutter strømmen.Læsbar grænseflade med et par bekvemmelighedsmetoder. En .count() er ikke en af dem på nuværende tidspunkt, og i betragtning af den nuværende brugerflade ville det ikke give meget mening.
Svarende til resultatet returneret fra .stream()
metode, der er tilgængelig for markørobjekter, ville en "tælle" ikke give meget mening her, når du overvejer implementeringen, da den er beregnet til at behandle som en "strøm", hvor du til sidst skal nå en "afslutning", men ellers bare vil behandle indtil du kommer dertil.
Hvis du overvejede standardgrænsefladen "Cursor" fra driveren, er der nogle solide grunde til, at aggregeringsmarkøren ikke er den samme:
-
Markører tillader "modifikator"-handlinger at blive behandlet før udførelse. Disse falder ind under kategorierne
.sort(),.limit()og.skip(). Alle disse har faktisk modpartsdirektiver i aggregeringsrammen, som er specificeret i pipelinen. Som pipeline-stadier, der kunne vises "hvor som helst" og ikke kun som en efterbehandlingsmulighed til en simpel forespørgsel, ville dette ikke give meget mening at tilbyde den samme "markør"-behandling. -
Andre markørmodifikatorer inkluderer specialer som
.hint(),.min()og.max()som er ændringer til "indeksvalg" og behandling. Selvom disse kunne være nyttige for aggregeringspipelinen, er der i øjeblikket ingen enkel måde at inkludere disse i forespørgselsvalg. For det meste tilsidesætter logikken fra det foregående punkt ethvert punkt med at bruge den samme type grænseflade til en "Markør".
De andre overvejelser er, hvad du egentlig vil gøre med en markør, og hvorfor du "ønsker" en tilbage. Da en markør normalt er en "envejs tur" i den forstand, at de normalt kun behandles indtil en ende er nået og i brugbare "batches", så gør den en rimelig konklusion, at "tællingen" faktisk kommer til sidst, når faktisk den "kø" endelig er udtømt.
Selvom det er rigtigt, at standard "markør"-implementeringen faktisk rummer nogle tricks, er hovedårsagen, at dette blot udvider et "meta" datakoncept, da forespørgselsprofileringsmotoren skal "scanne" et vist antal dokumenter for at bestemme hvilke elementer, der skal returneres i resultatet.
Aggregeringsrammen spiller dog lidt med dette koncept. Da der ikke kun er de samme resultater, som ville blive behandlet gennem standardforespørgselsprofiler, men der er også yderligere trin. Ethvert af disse stadier har potentialet til at "ændre" det resulterende "antal", som faktisk ville blive returneret i "strømmen", der skal behandles.
Igen, hvis du vil se på dette fra et akademisk synspunkt og sige, at "Selvfølgelig skal forespørgselsmotoren beholde 'metadataene' for optællingen, men kan vi ikke spore, hvad der er ændret efter?". Dette ville være et rimeligt argument, og pipeline-operatører såsom $match
og $group
eller $unwind
og muligvis endda inklusive $project
og den nye $redact
, kunne alle betragtes som et rimeligt grundlag for at holde deres eget styr på de "behandlede dokumenter" i hvert pipelinetrin og opdatere det i "metadataene", der muligvis kunne returneres for at forklare det fulde antal pipelineresultater.
Det sidste argument er rimeligt, men overvej også, at implementeringen af et "Cursor"-koncept for aggregeringspipeline-resultaterne på nuværende tidspunkt er et nyt koncept for MongoDB. Det kunne retfærdigt argumenteres for, at alle "rimelige" forventninger ved det første designpunkt ville have været, at "de fleste" resultater fra at kombinere dokumenter ikke ville være af en størrelse, der var restriktiv for BSON-begrænsningerne. Men efterhånden som brugen udvides, ændres opfattelserne, og tingene ændrer sig for at tilpasse sig.
Så dette "kunne" muligvis ændres, men det er ikke sådan det "aktuelt" er implementeret. Mens .count() på en standardmarkørimplementering har adgang til "metadataene", hvor det scannede nummer er registreret, vil enhver metode på den aktuelle implementering resultere i at hente alle markørresultaterne, ligesom .itcount() gør i skallen.
Behandl "markør"-emnerne ved at tælle på "data"-hændelsen og udsende noget (muligvis en JSON-streamgenerator) som "tæller" til sidst. For ethvert brugstilfælde, der ville kræve en optælling "forud", ville det alligevel ikke virke som en gyldig brug af en markør, da outputtet helt sikkert ville være et helt dokument af en rimelig størrelse.