[SERVER-35561] $geoNear "distanceField" and "includeLocs" options unnecessarily overwrite existing paths Created: 12/Jun/18 Updated: 06/Dec/22 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | Aggregation Framework |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Kyle Suarez | Assignee: | Backlog - Query Optimization |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | neweng, open_todo_in_code, storch | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Query Optimization
|
| Backwards Compatibility: | Minor Change |
| Participants: |
| Description |
|
Consider a collection with documents of the shape
This aggregation using the $geoNear stage computes new fields in "nested":
However, the aggregation system overwrites the field "nested.field", even though it could be preserved. This behavior occurs if the existing document field shares a prefix with either the "distanceField" or "includeLocs" options. This ticket is a request to preserve as much existing information as possible. |
| Comments |
| Comment by Kyle Suarez [ 20/May/21 ] |
|
david.percy, that's a good point to consider. kateryna.kamenieva, do you have a sense if any actual users of $geoNear would actually want this feature? Maybe all we really need to do here is ensure the docs mention that you will overwrite the output destination, so that users who don't want that behavior make sure to use a different field. |
| Comment by David Percy [ 19/May/21 ] |
|
Would this make covered queries harder? We might need to read "nested" before we can write "nested.dist". Maybe this only matters in some weird cases involving arrays? If "nested" is an array of objects, and we're being consistent with $addFields, then writing "nested.dist" means writing "dist" to each object in the array. |