Compatibility Changes in MongoDB 3.6

$type: "array" Behavior Change

Starting in 3.6, $type: "array" and $type: 4 expressions match array fields that contain any element type.

In earlier versions, $type : "array" only matches array fields that contain nested arrays.

For example, a collection named c contains two documents:

{ "_id": 1, "a": [ 1, 2, 3 ] },
{ "_id": 2, "a": [ 1, 2, [ 3, 4 ] ] }

The following operation queries by type on field a:

db.c.find( { "a": { $type : "array" } } )

Starting in 3.6, the query returns both documents in the collection because the $type query can now detect that field a is itself an array.

{ "_id": 1, "a": [ 1, 2, 3 ] },
{ "_id": 2, "a": [ 1, 2, [ 3, 4 ] ] }

In 3.4 and earlier versions of MongoDB, the query only returns those documents in which the array field a contains an element of BSON type array.

{ "_id": 2, "a": [ 1, 2, [ 3, 4 ] ] }

If upgrading from a MongoDB 3.4.x deployment that has partial indexes whose partialFilterExpression includes a $type : "array" or $type : 4 expression, you must rebuild these indexes after upgrading to avoid conflicting $type : 'array' semantics.

For more information on the $type: "array" expression, see Querying by Array Type.

Array Sort Behavior

Starting in 3.6, when sorting a field containing an array, MongoDB orders the field with the lowest-valued element of the array first for ascending sorts and the highest-valued element of the array first for descending sorts. A sort no longer takes the query predicate into account when choosing the array element which will act as the sort key. This behavior change applies to both the find command and the aggregation pipeline.

As a result of this change, applications that currently sort by an array field may experience a different sort order.

{ _id: 0, a: [-3, -2, 2, 3] }
{ _id: 1, a: [ 5, -4 ] }

db.coll.find({a: {$gte: 0}}).sort({a: 1});

{ "_id" : 1, "a" : [ 5, -4 ] }
{ "_id" : 0, "a" : [ -3, -2, 2, 3 ] }

{ _id: 0, a: [-3, -2, 2, 3] }
{ _id: 1, a: [ 5, -4 ] }

// Documents.
{ "_id" : 1, "timestamps" : [ ISODate("2017-07-15T15:31:01Z"), ISODate("2017-07-21T18:31:01Z") ] }
{ "_id" : 0, "timestamps" : [ ISODate("2017-07-21T15:31:01Z"), ISODate("2017-07-21T13:31:01Z") ] }
// Query.
db.c.aggregate([{$sort: {timestamps: -1}}])

// Documents.
{_id: 0, a: [3, 1, 5]}
{_id: 1, a: [3, 4, 0]}
// Query.
db.coll.aggregate([{$sort: {a: 1}}])

{a: [ {b: [1, 2]}, {b: [3, 4]} ]}

db.coll.aggregate([{$sort: {"a.b": 1}}])

{a: [{b: 1, c: 1}, {b: 2, c: 2}]}

db.coll.aggregate([{$sort: {"a.b": 1, "a.c": 1}}])

{ _id: 1, a: [ 1, 2 ], b: [ 1, 2 ]}
{ _id: 2, a: [ -3, 5 ], b: 0 }
{ _id: 3, a: [ -6, 12 ], b: 100 }

db.coll.aggregate([ { $sort: {a: 1, b: 1} } ])

New Fields in Updates

Starting in MongoDB 3.6, new fields added through update operations are appended in lexicographic order.

For example, a collection coll has the following document:

{ _id: 0, x: 0 }

The following update operation adds two new fields to the document:

db.coll.update({_id: 0}, {$set: {b: 0, a: 0}})

Starting in 3.6, MongoDB appends the new fields in lexicographic order. The updated document would be {_id : 0, x: 0, a: 0, b: 0}.

Earlier versions of MongoDB append the new fields in order of appearance in the update document. The updated document would be {_id : 0, x: 0, b: 0, a: 0}.

Fields Conflicting with arrayFilters Identifiers

Starting in MongoDB 3.6, fields that conflict with arrayFilters identifiers can no longer be updated.

For example, a collection coll has the following document:

{ _id: 0, x: { "$[]": 0 } }

The following update succeeds in earlier versions of MongoDB:

db.coll.update({_id: 0}, {$set: {"x.$[]": 1}})

In MongoDB 3.6 the update fails since the field name "$[]" conflicts with arrayFilters identifier syntax. For more information on arrayFilters see Specify arrayFilters for Array Update Operations.

Stricter Validation of $pop Arguments

Starting in 3.6 [1], $pop operator performs a stricter validation of its argument to require either:

• -1 to remove the first element of an array, or

• 1 to remove the last element in an array.

In earlier versions, $pop allowed:

• any value less than 0 to remove the first element of an array, and

• any value greater than or equal to 0 as well as non-numeric value to remove the last element in an array.

Remove $pushAll Update Operator

MongoDB 3.6 removes the deprecated $pushAll operator. The operator has been deprecated since 2.4.

Instead of $pushAll, use the $push operator with the $each modifier. For example:

db.students.update(
   { name: "joe" },
   { $push: { scores: { $each: [ 90, 92, 85 ] } } }
)

MONGODB-CR Deprecation

As of MongoDB 3.6, MONGODB-CR authentication mechanism is deprecated. If you have not upgraded your MONGODB-CR authentication schema to SCRAM, see Upgrade to SCRAM.

Arbiter and Priority

Arbiters have priority 0.

Deprecate Master-Slave Replication

MongoDB 3.6 deprecates master-slave replication.

--nojournal Option with WiredTiger

In version 3.6, the --nojournal option is deprecated for Replica Set Members using the WiredTiger storage engine.

Replica set members that use the WiredTiger storage engine should not use the --nojournal option. For more information about journaling, see Manage Journaling.

aggregate Command and Results

MongoDB 3.6 removes the option for the aggregate command to return its results as a single document.

If you run the aggregate command, you must include either the cursor option or the explain option.

Rather than run the aggregate command directly, most users should use the db.collection.aggregate() helper provided in the mongo shell or the equivalent helper in their driver. These helpers return a cursor unless using the explain option.

Aggregation Date to String Coercion

Starting in 3.6, a date coerced to a string in an aggregation expression will include milliseconds and is appended with the letter 'Z'.

// Documents.
{_id: 0, d: ISODate("2017-10-18T20:04:27.978Z")}
{_id: 1, d: ISODate("2017-10-18T20:04:28.192Z")}
// Query.
db.coll.aggregate({$project: {d: {$toLower: "$d"}}})

Prior to 3.6, this would return the dates as d: "2017-10-18t20:04:27" and d: "2017-10-18t20:04:28" respectively. In 3.6, the results include the milliseconds and letter 'Z': d: "2017-10-18t20:04:27.978z" and d: "2017-10-18t20:04:28.192z".

The change applies to the following aggregation operators:

• $concat

• $substr

• $substrBytes

• $substrCP

• $strcasecmp

• $toLower

• $toUpper

Remove Diagnostic Logging Command and Option

MongoDB 3.6 removes the deprecated diagLogging command and mongod --diaglog option. Instead, use mongoreplay to capture, replay, and profile commands sent to your MongoDB deployment.

validate Operation

Starting in MongoDB 3.6, for the WiredTiger storage engine, only the full validation process will force a checkpoint and flush all in-memory data to disk before verifying the on-disk data.

In previous versions, the data validation process for the WT storage engine always forces a checkpoint.

For more information on the validate operation, see the validate command and the db.collection.validate() method.

Indexes Named *

Starting in 3.6, you cannot specify * as the index name during index creation nor can you delete indexes named * by specifying the index keys.

To delete existing indexes named *, delete the index before upgrading. To rename them, delete and recreate the index.

Deprecated Options

• MongoDB 3.6.1 deprecates the snapshot query option.

  For MMAPv1, use hint() on the { _id: 1} index instead to prevent a cursor from returning a document more than once if an intervening write operation results in a move of the document.

  For other storage engines, use hint() with { $natural : 1 } instead.

• MongoDB 3.6.1 deprecates the $isolated option. For more information on read isolation, see Read Isolation, Consistency, and Recency. [2]