[SERVER-27265] Fast bsonExtract handling for NoSuchKey + no default, in non-error case Created: 02/Dec/16 Updated: 06/Dec/22 Resolved: 30/Jun/17 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | James Wahlin | Assignee: | Backlog - Query Team (Inactive) |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Assigned Teams: |
Query
|
||||||||||||
| Sprint: | Platforms 2017-06-19 | ||||||||||||
| Participants: | |||||||||||||
| Description |
|
The bsonExtract* methods in bsonExtract.cpp are often used to both determine whether a field exists and in the case it does parse out of a BSONObj, with both results being considered valid. In the case where a field does not exist we generate an error Status object and build an error message using str::stream() both of which are expensive operations for a non-error path. We should consider adding methods (or modifying current ones) to support extraction or fast NoSuchKey return in the case the field doesn't exist (without return of an error Status object). This ticket should focus on the methods outside of the "WithDefault" ones, which will be handled under After completing this ticket we should perform an audit of the code base and enter follow-on tickets to address cases where NoSuchKey is being handled after bsonin a non-error situation. A few (out of many) examples of this: |
| Comments |
| Comment by Andrew Morrow (Inactive) [ 27/Jun/17 ] |
|
This is basically an entirely new set of APIs into the bsonExtract library, since it would necessarily have a different return type than Status (bool?). If such an API would be advantageous for the query team, it would be straightforward for them to implement. It is also unclear to me whether there is long term value in the bson_extract APIs given the arrival of IDL. Handing back to query team for triage. |
| Comment by Tyler Kaye [ 21/Jun/17 ] |
|
Re-assigning this to you to determine if a new interface is needed or whatnot. |