[SERVER-24198] When planning fails because there is no way to answer the query, it should emit ErrorCodes::NoQueryExecutionPlans Created: 18/May/16 Updated: 06/Dec/22 Resolved: 08/Oct/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Querying |
| Affects Version/s: | 3.2.6 |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Tyler Brock | Assignee: | Backlog - Query Team (Inactive) |
| Resolution: | Done | Votes: | 1 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Assigned Teams: |
Query
|
||||||||
| Participants: | |||||||||
| Case: | (copied to CRM) | ||||||||
| Description |
| Comments |
| Comment by David Storch [ 08/Oct/19 ] |
|
This improvement was completed as part of related ticket |
| Comment by Matthew Monteleone [ 03/Sep/19 ] |
|
As an additional perspective on this....
Since this option is exposed in the Atlas interface, more customers with less experience with MongoDb may be faced with the current error message. The current error message can be a bit cryptic to these users. The more specific {{NoQuerySolutionMissingRequiredIndex }}could be very useful in reducing customer frustration and reducing support load. |
| Comment by David Storch [ 18/May/16 ] |
I think NoQuerySolutions is better. The only way this can happen is 1) you issue a geoNear query without the right geo index, 2) you issue a text query without a text index, or 3) the plan would be a collection scan but you have disabled collection scans via --notablescan.
Definitely not ErrorCodes::BadValue |
| Comment by Tyler Brock [ 18/May/16 ] |
|
Ah, thanks dstorch. Can we add something like ErrorCodes::NoQuerySolutionMissingRequiredIndex to make it more explicit or is that too verbose and specific? In your mind what would the best way to catch this particular error for a missing 2d index for a geo query on MongoDB spanning multiple versions? Would a regex match for "unable to find index for $geoNear query" on error message do the trick or is there a better way? |
| Comment by David Storch [ 18/May/16 ] |
|
I would say this is expected behavior. The query planner has always issued ErrorCodes::BadValue when it detects that a $near query cannot be answered in the absence of a matching geospatial index. Previous versions of the server converted this error status into a user assertion exception with code 17007 in order to propagate the error to the client. In 3.2, we made a change that caused us to propagate the original error status rather than changing it to 17007. (By the way, 17007 was never reserved for this particular geo-related error case; I think there are many kinds of query planning or query execution errors that could result in 17007.) That said, I think we could be using a better / more specific error code here instead of ErrorCodes::BadValue. I'm going to repurpose this ticket as a request to add ErrorCodes::NoQuerySolution. |