[DOCS-16634] [SERVER] Investigate changes in SERVER-84598: $geoNear allows missing or invalid GeoJSON "type" field Created: 06/Feb/24 Updated: 06/Feb/24 |
|
| Status: | Backlog |
| Project: | Documentation |
| Component/s: | Server |
| Affects Version/s: | None |
| Fix Version/s: | 7.3.0-rc0 |
| Type: | Task | Priority: | Minor - P4 |
| Reporter: | Backlog - Core Eng Program Management Team | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | feature, query | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Participants: | |||||||||
| Days since reply: | 1 day ago | ||||||||
| Description |
|
Original Downstream Change Summary Just a heads up for docs that even though this behavior was technically not allowed before, it will now error. Description of Linked TicketMost geo queries that are built on top of geometry_container do not allow an unknown or missing "type" field. However, $geoNear (match expression and agg stage) rely instead on `GeoNearExpression`, which skips the geometry_container layer, so it accepts a missing or invalid GeoJSON "type" field, and will treat it as type "Point". In fact, it would even accept the type field as any GeoJSON type, since it doesn't check the "type" field. This is misleading, and inconsistent with the other geo operators. As part of this ticket, we should consider incorporating geometry_container as part of GeoNearExpression to match behavior parity across geo expressions. |
| Comments |
| Comment by Education Bot [ 06/Feb/24 ] |
|
Fix Version updated for upstream |
| Comment by Education Bot [ 06/Feb/24 ] |
|
Fix Version updated for upstream |