Starting in 2.6.0-rc0, there are two versions of 2dsphere indexes. All new 2dsphere indexes starting in 2.6.0-rc0 are created with {2dsphereIndexVersion:2}. The V2 behavior is consistent with the behavior of 2d indexes with regards to 'sparseness'
{2dsphereIndexVersion: 1} indexes:
- Do not support new GeoJSON geometries introduced in 2.5.0: (MultiPoint, MultiLineString, MultiPolygon,
GeometryCollection). - Are not sparse and do not recognize the
{sparse: true}
index modifier.
- Documents which contain null or "empty" [] for the geo field are rejected and not inserted into the collection.
- Documents with the geo field undefined are indexed and added to the collection.
- It is possible to preserve the V1 behavior by indicating the version when creating the index. See
SERVER-12175.
For example, coll.ensureIndex( {geo: "2dsphere"}, {"2dsphereIndexVersion": 1});
{2dsphereIndexVersion: 2} indexes:
- Ignore the sparse flag and print a warning to the server log if it's set.
- If a document lacks a 2dsphere-indexed field (or the field is null or an empty array) the document is inserted but not added to the index.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Original Ticket Description
2dsphere indexes does not honor the sparse option. By contrast, 2d indexes are "sparse" by default and require all the fields from the index definition to be present in the document for the document to be included in the index.
Don't know if this is an oversight or by design, but sparse functionality for 2dsphere is usable in the same way as sparse is usable for "normal" indexes.
- is duplicated by
-
SERVER-10709 Invalid BSON docs lead to errors in complex queries
- Closed
-
SERVER-9926 2dsphere index requires field. "Can't parse geometry from element: location: null"
- Closed
-
SERVER-10095 2dsphere index creation fails with null coordinates values
- Closed
- is related to
-
SERVER-11149 Make 2dsphere indexes adhere to normal sparse index rules
- Closed