[SERVER-1990] $near and $maxDistance shouldn't require a particular order Created: 22/Oct/10 Updated: 06/Dec/22 Resolved: 12/Jul/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Geo |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Minor - P4 |
| Reporter: | Kyle Banker | Assignee: | Backlog - Query Team (Inactive) |
| Resolution: | Won't Do | Votes: | 11 |
| Labels: | query-44-grooming | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Assigned Teams: |
Query
|
||||||||
| Operating System: | ALL | ||||||||
| Participants: | |||||||||
| Description |
|
I think these should be synonymous: db.collection.find( { latlng : { $near : [50,50] , $maxDistance : 5 } } ) } ) |
| Comments |
| Comment by David Storch [ 12/Jul/19 ] | ||||||||||||
|
Since this issue does not affect the newer syntax for $near operations, I'm closing this ticket as "Won't Do". | ||||||||||||
| Comment by Asya Kamsky [ 05/Feb/18 ] | ||||||||||||
|
New preferred geo syntax is documented here and it does not have this issue. Only legacy $near on legacy 2d indexes have this issue.
| ||||||||||||
| Comment by Asya Kamsky [ 10/Nov/13 ] | ||||||||||||
|
Use Tie::IxHash http://search.cpan.org/~chorny/Tie-IxHash-1.23/lib/Tie/IxHash.pm ? | ||||||||||||
| Comment by Andrew Skripnikov [ 08/Nov/13 ] | ||||||||||||
|
+1. Unable to use $near in Perl order: $addr_cur=$db->get_collection('geo_cache')->query({ })->limit(1); Because can't sort hash output in Perl. Mongo 2.4.8 | ||||||||||||
| Comment by Dan Harasty [ 28/Sep/13 ] | ||||||||||||
|
+1 for a fix to this. (workaround given in: http://stackoverflow.com/questions/10020755/mongomapper-near-with-maxdistance-mongooperationfailure-geo-values-have-to) | ||||||||||||
| Comment by Raviteja [ 31/Jul/12 ] | ||||||||||||
|
This has to be fixed, this behavior doesn't make any sense. I was having this problem with mongoengine over pymongo. | ||||||||||||
| Comment by don'catnip [ 23/Oct/11 ] | ||||||||||||
|
I'd like to see this fixed too, because this behaviour does not make any sense and developers have to pay atleast some amount of time to figure out why their queries are not working. | ||||||||||||
| Comment by Eliot Horowitz (Inactive) [ 05/May/11 ] | ||||||||||||
|
You can use SON in pymongo to get an ordered dict | ||||||||||||
| Comment by Andrew Staub [ 05/May/11 ] | ||||||||||||
|
I'm having this problem with pymongo. Is there a known solution? | ||||||||||||
| Comment by Wancharle Sebastiao Quirino [ 21/Mar/11 ] | ||||||||||||
|
i find this issue in pymongo too. | ||||||||||||
| Comment by Ray Krueger [ 29/Dec/10 ] | ||||||||||||
|
Actually this is a problem with the ruby driver in general when using anything less than ruby 1.9. | ||||||||||||
| Comment by Ray Krueger [ 29/Dec/10 ] | ||||||||||||
|
This just bit me using while using mongomapper. The translation from hash to json ends up losing any ordering. |