[SERVER-8131] Aggregation's $sort does not support $natural. Created: 09/Jan/13 Updated: 25/Feb/20 Resolved: 25/Feb/20 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Aggregation Framework |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Minor - P4 |
| Reporter: | Richard Kreuter (Inactive) | Assignee: | David Storch |
| Resolution: | Won't Do | Votes: | 6 |
| Labels: | grab-bag, query-44-grooming, usability | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Sprint: | Query 2020-03-09 |
| Participants: |
| Description |
|
This is dumb, but {$sort : {$natural:1}}, and the error message is unclear. Options: continue not to support it, make the error message better. |
| Comments |
| Comment by David Storch [ 25/Feb/20 ] | ||||||||||||||||||||||||||
|
The Query Team has decided not to implement this improvement, so I'm closing the ticket as "Won't Do". We reason that {$sort: {$natural: 1}} in an aggregation pipeline is not always a meaningful operation. For find commands, applications can make use of $natural hint or $natural sort for two purposes:
Note that for non-capped collections there are no specific ordering guarantees provided by $natural sort; instead, the guarantee is that the data access plan will be a collection scan. It is not possible to take a logical bag of documents and compute their $natural sort order. Such an operation is not well defined. Consider the following motivating example:
Here we are summing across the counter field for each group of documents with the same groupKey value. It's not clear what it would mean to sort the resulting set of documents by {$natural: 1}. Would this sort operation simply be a no-op? Users who wish to force a COLLSCAN or ensure capped collection insertion order using the aggregation framework can specify $natural as a hint. (Hint support for the aggregate command was added in 3.6 by It is unfortunate that sort accepted by a find command is not 100% identical to the syntax of the $sort aggregation stage due to this difference in $natural support, but we have chosen to live with this inconsistency. | ||||||||||||||||||||||||||
| Comment by Asya Kamsky [ 07/Jul/19 ] | ||||||||||||||||||||||||||
|
Just to expand. Forcing a $natural order via using an index hint has the same effect as
| ||||||||||||||||||||||||||
| Comment by Asya Kamsky [ 07/Jul/19 ] | ||||||||||||||||||||||||||
|
Note that aggregation takes hint value $natural:1 but not explicit sort value. | ||||||||||||||||||||||||||
| Comment by Scott Glajch [ 09/Aug/18 ] | ||||||||||||||||||||||||||
|
I would like {$natural: -1} to be supported in aggregations. This would be helpful to help dig in to our writes via the oplog collection, which while it is naturally sorted via the "ts" attribute, doesn't have any indexes, so I have no performant option to sort on this other than doing natural: -1 (to get the most recent N events). | ||||||||||||||||||||||||||
| Comment by John Page [ 21/Oct/13 ] | ||||||||||||||||||||||||||
|
I wanted to do a divde and conquer on the first and second half of the data and this prevented it . | ||||||||||||||||||||||||||
| Comment by Will Shaver [ 22/May/13 ] | ||||||||||||||||||||||||||
|
Current error: Would be great to support {$natural: -1} for $sort |