[SERVER-13974] Support $near in $or Created: 16/May/14  Updated: 06/Dec/22  Resolved: 03/Feb/22

Status: Closed
Project: Core Server
Component/s: Geo, Querying
Affects Version/s: 2.6.1
Fix Version/s: features we're not sure of

Type: Improvement Priority: Major - P3
Reporter: Mathieu Carbou Assignee: Backlog - Query Optimization
Resolution: Won't Fix Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by SERVER-55612 Improve handling of $geonear+$or when... Closed
Related
is related to SERVER-15746 'Can't canonicalize query' error when... Closed
Assigned Teams:
Query Optimization
Participants:

 Description   

Query with toplevel $or containing one geo $near query plus another one.

=> Error: Can't canonicalize query: BadValue geoNear must be top-level expr

Please add support for this feature



 Comments   
Comment by David Percy [ 03/Feb/22 ]

I don't think we should support this syntax, because it's not clear what the expected behavior would be:

  • If only one branch of the $or uses $near, what order does the other branch use?
  • If both branches use $near, how are the results interleaved? Does it matter if they're querying two different location fields?
  • If one document matches both $near predicates, with a different center point, what should the distance be?

But depending on what you're trying to do, there may already be a better way:

If you don't care about the order, you can use $geoWithin $center / $centerSphere to select documents within a circular region. You can combine multiple $geoWithin predicates with $or, and you can specify more complex shapes using GeoJSON.

Now that we have $unionWith, it's also possible to combine two $geoNear queries and explicitly sort the result:

db.places.aggregate([
  {$geoNear: {... distanceField: 'd' ...}},
  {$unionWith: {
    coll: 'places',
    pipeline: [
      {$geoNear: {... distanceField: 'd' ...}},
    ]
  }},
  {$sort: {d: 1}},
])

Today this does a blocking sort at the end, but in the future we could optimize it to a merge sort: SERVER-48120.

Unlike $or, $unionWith preserves duplicates, so maybe you would also want to $group by something.

Comment by Abhinandan Kothari [ 17/Sep/18 ]

Any update on this?

Is there any chance that we will get it in near future?

Comment by hari.khalsa@10gen.com [ 19/May/14 ]

We disallow this because $near implies a sort by distance and it's not clear what the sort order would be if the $near was or'd with a non-near clause. Unless we have a good answer for how the documents should be ordered we don't plan on supporting this.

CC greg_10gen

Generated at Thu Feb 08 03:33:27 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.