-
Type: Task
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: None
-
None
-
Query Execution
-
Fully Compatible
drew.paroski 4:48 PM
Re: ideas of stuff to work on this week, one thing that would be valuable would be to improve our test coverage of $topN and $bottomN (the "N" versions specifically).
At one of the manager/stakeholder meetings a week or 2 ago, there was some skepticism about whether $topN and $bottomN would be ready and stable enough by Apr 2 to ship them as part of 8.0. (This meeting happened a day before the implementation of $top/$topN/$bottom/$bottomN was committed to master.)
I'd like to be able to come back to those managers / stakeholders and say "hey, we've had this working implementation in master for a few weeks now and we have a good amount of testing and think we've rooted out all the bugs, let's ship this as part of 8.0." Having more testing on $topN and $bottomN would help me/us do that.
...
I'd like to add more test coverage for $top/$bottomN.
For example, what if we supply a big value for "n" (1,000,000) or huge value for "n" (1e50)? Do we behave correctly in these cases?
What if we reference the same field multiple times in the "sortBy" pattern. Does that work correctly?
What if the "sortBy" pattern references a field that is also referred to in the $group's "_id" field? Does that work correctly?
Is there anything interesting we can test with $group queries that have multiple $topN and $bottomN accumulators?
That's the kind of stuff I'm thinking of.