Dit verdient mogelijk een volledige uitleg voor degenen die hiernaar zoeken, dus voeg er een toe voor het nageslacht.
Wat specifiek wordt geretourneerd, is een gebeurtenisstroom voor node.js die de stream.Readable
effectief omhult een> interface met een aantal gemaksmethoden. Een .count() is momenteel niet een van hen en gezien de huidige gebruikte interface zou het niet veel zin hebben.
Vergelijkbaar met het resultaat van de .stream()
methode beschikbaar is voor cursorobjecten, zou een "telling" hier niet veel zin hebben als je de implementatie overweegt, omdat het bedoeld is om te verwerken als een "stroom" waar je uiteindelijk een "einde" gaat bereiken, maar anders gewoon wilt verwerken totdat je er bent.
Als je de standaard "Cursor"-interface van het stuurprogramma hebt overwogen, zijn er enkele solide redenen waarom de aggregatiecursor niet hetzelfde is:
-
Met cursors kunnen "modificatie"-acties worden verwerkt voordat ze worden uitgevoerd. Deze vallen in de categorieën
.sort(),.limit()en.skip(). Al deze hebben in feite tegenhangerrichtlijnen in het aggregatieraamwerk die in de pijplijn worden gespecificeerd. Aangezien pijplijnstadia "overal" zouden kunnen verschijnen en niet alleen als een nabewerkingsoptie voor een eenvoudige zoekopdracht, zou het niet veel zin hebben om dezelfde "cursor" -verwerking aan te bieden. -
Andere cursormodifiers zijn specials zoals
.hint(),.min()en.max()dat zijn wijzigingen in "indexselectie" en verwerking. Hoewel deze nuttig kunnen zijn voor de aggregatiepijplijn, is er momenteel geen eenvoudige manier om deze op te nemen in de selectie van zoekopdrachten. Meestal overschrijft de logica van het vorige punt elk punt van het gebruik van hetzelfde type interface voor een "cursor".
De andere overwegingen zijn wat u eigenlijk met een cursor wilt doen en waarom u er een wilt retourneren. Aangezien een cursor meestal een "enkele reis" is in de zin dat ze meestal alleen worden verwerkt tot een einde is bereikt en in bruikbare "batches", dan maakt het een redelijke conclusie dat de "telling" eigenlijk pas aan het einde komt, terwijl in feite die "wachtrij" eindelijk is uitgeput.
Hoewel het waar is dat de standaard "cursor"-implementatie in feite enkele trucjes bevat, is de belangrijkste reden dat dit alleen maar een uitbreiding is van een "meta" -gegevensconcept, aangezien de queryprofileringsengine een bepaald aantal documenten moet "scannen" om te bepalen welke items om terug te keren in het resultaat.
Het aggregatieraamwerk speelt echter een beetje met dit concept. Omdat er niet alleen dezelfde resultaten zijn als zouden worden verwerkt via de standaard queryprofiler, maar er zijn ook extra fasen. Elk van deze fasen heeft het potentieel om de resulterende "telling" te "wijzigen" die daadwerkelijk zou worden geretourneerd in de "stroom" die moet worden verwerkt.
Nogmaals, als je dit vanuit een academisch oogpunt wilt bekijken en zegt:"Natuurlijk, de query-engine moet de 'metadata' voor de telling behouden, maar kunnen we niet volgen wat er daarna wordt gewijzigd?". Dit zou een redelijk argument zijn, en pijpleidingbeheerders zoals $match
en $group
of $unwind
en mogelijk zelfs inclusief $project
en de nieuwe $redact
, kunnen allemaal worden beschouwd als een redelijk argument om hun eigen spoor van de "documenten verwerkt" in elke pijplijnfase bij te houden en die bij te werken in de "metagegevens" die mogelijk kunnen worden geretourneerd om het volledige aantal pijplijnresultaten uit te leggen.
Het laatste argument is redelijk, maar bedenk ook dat op dit moment de implementatie van een "Cursor"-concept voor de aggregatiepijplijnresultaten een nieuw concept is voor MongoDB. Men zou eerlijk kunnen stellen dat alle "redelijke" verwachtingen bij het eerste ontwerppunt zouden zijn geweest dat de "meeste" resultaten van het combineren van documenten niet van een grootte zouden zijn die beperkend was voor de BSON-beperkingen. Maar naarmate het gebruik toeneemt, veranderen de percepties en veranderen dingen om zich aan te passen.
Dit "zou" dus mogelijk kunnen worden veranderd, maar het is niet hoe het "momenteel" wordt geïmplementeerd. Terwijl .count() op een standaard cursorimplementatie toegang heeft tot de "metadata" waar het gescande nummer is vastgelegd, zou elke methode op de huidige implementatie resulteren in het ophalen van alle cursorresultaten, net zoals .itcount() doet in de schaal.
Verwerk de "cursor" -items door te rekenen op de "data" -gebeurtenis en aan het einde iets uit te zenden (mogelijk een JSON-stroomgenerator) als de "telling". Voor elk gebruik dat een telling "van tevoren" zou vereisen, lijkt het sowieso geen geldig gebruik voor een cursor, aangezien de uitvoer zeker een heel document van een redelijke grootte zou zijn.