-
Type: New Feature
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: None
-
None
-
Fully Compatible
-
Query Optimization 2021-07-26, QO 2021-09-06, Query Optimization 2021-08-09, QO 2021-09-20, QO 2021-08-23
Currently, 'near' has to be a literal array (or GeoJSON object):
> db.c.aggregate([ {$geoNear: {near: [0, 0]}} ]
Instead we should allow it to be an expression:
> db.c.aggregate([ {$geoNear: {near: "$$pt"}} ], {let: {pt: [0, 0]}})
It doesn't make sense to allow the query point to vary per-document, so it has to be a constant expression.
We also want to allow 'near' to be bound in a $lookup:
{$lookup: { from: 'coll', as: 'docs', let: {pt: "$location"}, pipeline: [ {$geoNear: { near: "$$pt", ... }} ] }}
The expression "$$pt" is constant within each subquery.
To make this work I think we'll want to:
- Change the DocumentSourceGeoNear parser to accept any expression, for 'near'.
- Change DocumentSourceGeoNear::optimize to optimize the expression.
- When we convert DocumentSourceGeoNear to DocumentSourceGeoNearCursor, raise an error if the expression is not a constant.
- is depended on by
-
COMPASS-5103 Allow $geoNear 'near' argument to be a let variable (string with $$)
- Closed
-
TOOLS-2954 Investigate changes in SERVER-58604: Allow $geoNear 'near' argument to be a let variable
- Closed
- is duplicated by
-
SERVER-34766 Allow $expr or $$field in the $geoNear stage
- Closed
- is related to
-
SERVER-37675 Allow $geoWithin and $geoIntersects to take their geometry from an expression
- Backlog