[SERVER-14083] Regression from 2.4.x -> 2.6.x in order of $or Created: 29/May/14 Updated: 10/Dec/14 Resolved: 29/May/14 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Querying |
| Affects Version/s: | 2.6.0 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Daniel Doubrovkine | Assignee: | David Storch |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Operating System: | ALL | |||||||||||||||||||||||||||||||||||
| Steps To Reproduce: |
|
|||||||||||||||||||||||||||||||||||
| Participants: |
| Description |
|
We used to rely on $or to return an ordered result set. 2.6.? no longer does that. I understand that was never documented as a feature, but it's pretty clear that lots of people do that , see http://stackoverflow.com/questions/3142260/order-of-responses-to-mongodb-in-query for example. |
| Comments |
| Comment by David Storch [ 29/May/14 ] | |
|
Hi dblock, fair point, this should be documented. I opened | |
| Comment by Daniel Doubrovkine [ 29/May/14 ] | |
|
David, I agree that this works as designed. However, I know at least a handful of companies relying on this behavior that has often been described in email threads from 10gen developers, so you're going to see some surprised people. At the least, I would document this in the changelog or something like that? | |
| Comment by David Storch [ 29/May/14 ] | |
|
Hi dblock, Thanks for the bug report with detailed repro steps! In general, MongoDB does not guarantee that the results are returned in any particular order, unless the query has a .sort(...). (One exception is geoNear queries, which return results sorted by descending distance.) A regular .find() query with .sort() is allowed to return its result set in any order. To answer the query
the query planner might decide to scan index {b: 1} which means that you would get results back in order of ascending "b". But relying on this ordering is bad because someday the planner might decide to use index {a: 1} instead. So the bottom line is "never expect a sort without a .sort()". Read on if you're curious about the internal details regarding why this particular use no longer provides the same sort order. The different ordering between 2.4.x and 2.6.x was the result of query normalization that was added in 2.6.0. Previous versions of MongoDB would sometimes behave differently for logically equivalent queries based on the ordering of the query predicates: for example, query {a: 5, b: 7} might behave differently than {b: 7, a: 5}. Queries within a logical equivalence class are now normalized to the same canonical form. One consequence is that the ordering of $or clauses is no longer significant, which causes the behavior change described by this ticket. I hope this explanation is helpful, and please feel free to reach out with further questions or concerns. Best, | |
| Comment by Daniel Doubrovkine [ 29/May/14 ] | |
|
Ruby workaround w/ Mongoid: https://gist.github.com/dblock/d5ed835f0147467a6a27 |