[DOCS-11099] Docs for SERVER-31651: geoNear command and $geoNear agg stage should accept a "key" field Created: 08/Dec/17 Updated: 29/Oct/23 Due: 04/May/18 Resolved: 25/Jun/18 |
|
| Status: | Closed |
| Project: | Documentation |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 3.7.1 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Kay Kim (Inactive) | Assignee: | Allison Reinheimer Moore |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | docs-grab-0504 | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Participants: | |||||||||
| Days since reply: | 5 years, 18 weeks, 1 day ago | ||||||||
| Epic Link: | DOCS: 4.0 Server | ||||||||
| Description |
Scope of changes:There are several things to document related to the changes for this ticket.
We document in several places that minDistance is only allowed for near queries that use a "2dsphere" index:
This is no longer the case.
This is subtle and kind of confusing. The old behavior was that, for any geoNear/$geoNear using a "2dsphere" index, the command would fail unless spherical was explicitly specified as true. We currently document that spherical is required for "2dsphere" indexes in a few places:
This ticket changes the spherical option such that spherical=true is identical in meaning to the $nearSphere query predicate and spherical=false is identical in meaning to the $near query predicate. This means that:
I think this behavior could be summarized in two ways. The first is "The spherical flag controls whether $near or $nearSphere semantics are used." The second is, "When using a '2d' index, the spherical flag controls whether to calculate distances using a planar or spherical geometry". In any case, we need to remove the sentences that say "Required if using a 2dsphere index.". 3) This ticket adds a new key param which is accepted by both the geoNear command and the $geoNear stage, and is used to specify the field path over which to compute the near. This parameter needs to be documented in both places. We should probably also add an example. Finally, we need to remove or modify sentences like this one: "However, the geoNear command requires that a collection have at most only one 2dsphere and/or only one 2d index ." This is no longer true, since key can be used to disambiguate in the case of multiple geo indexes in the same collection. Feel free to reach out to me with any questions and/or send a code review my way! Impact to other docs outside of this product:MVP:Resources:Engineering Ticket Description:The geoNear command and the $geoNear agg stage currently infer the field path over which to perform the search based on the presence of a "2d" or "2dsphere" index: The command will fail if there are multiple geo indexes. In order to improve this behavior, we should extend the command and agg stage to accept an optional key field. This field must be a string, and will be interpreted as the field path over which to run the search. In order to avoid breaking existing applications, the existing behavior should be preserved when the key field is omitted. |
| Comments |
| Comment by Githook User [ 09/Oct/18 ] |
|
Author: {'name': 'kay', 'email': 'kay.kim@10gen.com', 'username': 'kay-kim'}Message: |
| Comment by Githook User [ 21/Aug/18 ] |
|
Author: {'name': 'kay', 'email': 'kay.kim@10gen.com', 'username': 'kay-kim'}Message: |
| Comment by Githook User [ 21/Aug/18 ] |
|
Author: {'name': 'kay', 'email': 'kay.kim@10gen.com', 'username': 'kay-kim'}Message: |
| Comment by Githook User [ 25/Jun/18 ] |
|
Author: {'username': 'schmalliso', 'name': 'Allison Reinheimer Moore', 'email': 'allison.moore@10gen.com'}Message: |