:Compatibility changes in MongoDB 3.6

$type: "array" behavior changes

Starting from MongoDB 3.6, the type: "array" and $type: 4 expressions match array fields that contain any elements type.

Prior to MongoDB 3.6, $type: "array" only matches array fields that contain nested arrays.

For example, a collection named c contains the following documents:

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

The following operation queries data by the type of field a:

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

Starting from MongoDB 3.6, a $type query returns the two documents in the collection because the query now detects that field a is an array.

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

Prior to MongoDB 3.4, a $type query only returns documents where field a contains elements of the BSON array type.

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

If your current instance runs MongoDB 3.4.x and you are using partial indexes whosepartialFilterExpression contains $type: "array" or $type: 4, you must rebuild these indexes after an upgrad to MongoDB 3.6, thereby avoiding conflicts due to semantic changes in $type: 'array'.

Array sorting behavior changes

Starting from MongoDB 3.6, when sorting on an array field, MongoDB uses the lowest-valued array element for an ascending sort key and the highest-valued array element for a descending sort key. A sort no longer considers query predicates when selecting an array element as a sort key. This behavior change applies to the find command and aggregation pipeline operations.

Consequently, applications that sort on an array field may return different sorting results.

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

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

// 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}}])

New field updates

Starting from MongoDB 3.6, fields added during update operations are appended in lexicographic order.

For example, a collection named coll contains the following document:

{ _id: 0, x: 0 }

Execute an update operation to add the following fields:

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

In MongoDB 3.6, new fields are appended in lexicographic order. Consequently, the updated document is {_id: 0, x: 0, a: 0, b: 0}.

Prior to MongoDB 3.6, new fields are appended in order of their appearance in the update document. Consequently, the updated document is {_id: 0, x: 0, b: 0, a: 0}.

Fields conflicting with arrayFilters identifier syntax

Starting from MongoDB 3.6, fields whose name conflict with arrayFilters identifier syntax (such as $[]) can no longer updated.

For example, a collection named coll contains the following document:

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

Execute an update operation:

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

Starting from MongoDB 3.6, an update operation succeeds. In MongoDB 3.6, an update operation fails because the field name $[] conflicts with arrayFilters identifier syntax.

Stricter validation of the $pop operator

Starting from MongoDB 3.6, the parameters of the $pop operator must be set to one of the following values:

• -1: removes the first element of an array, or

• 1: removes the last element of an array.

Prior to MongoDB 3.6:

• Negative numbers to remove the first element of an array, or

• Non-negative numbers or non-numeric values to remove the last element of an array.

Removal of the $pushAll operator

MongoDB 3.6 removes the $pushAll operator (deprecated since MongoDB 2.4).

Use the $push and $each operators instead. Example:

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

Deprecation of the MongoDB-CR authentication mechanism

Starting from MongoDB 3.6, MongoDB deprecates the MONGODB-CR authentication mechanism. If you have not, upgrade your MONGODB-CR authentication schema to SCRAM.

Arbiter nodes and their priority

All arbiter nodes have a fixed priority of 0.

Deprecation of master-slave replication architecture

MongoDB 3.6 officially deprecates the master-slave replication architecture.

Deprecation of the --nojournal option for the WiredTiger storage engine

MongoDB 3.6 deprecates the --nojournal option for replica set members that use the WiredTiger storage engine, thereby avoiding data risks.

Adjustments to the aggregate command and its output

Starting from MongoDB 3.6, the aggregate command no longer returns results as a single document.

When running the aggregate command, you must specify one of the following options:

• cursor: returns results as a cursor (suitable for large datasets).

• explain: returns an analysis of the execution plan for an aggregation pipeline.

We recommend that you use db.collection.aggregate() in the mongo shell or the equivalent method in your driver. These methods return a cursor by default unless the explain option is used.

Changes to conversion from date fields to strings in aggregation expressions

Starting from MongoDB 3.6, MongoDB forcibly converts a date to a string that contains millisecond precision and end with the letter 'Z' (indicating UTC timezone) in an aggregation expression.

Example:

// 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 MongoDB 3.6, data fields in the two documents are returned as strings in the "2017-10-18t20:04:27" and "2017-10-18t20:04:28" format.

Starting from MongoDB 3.6, data fields in the two documents are returned as strings in the "2017-10-18t20:04:27.978z" and "2017-10-18t20:04:28.192z" (including milliseconds and lowercase 'z') format.

The changes apply to the following aggregation operators:

• $concat

• $substr

• $substrBytes

• $substrCP

• $strcasecmp

• $toLower

• $toUpper

Removal of log diagnostics commands and options

MongoDB 3.6 removes deprecated diagLogging and mongod --diaglog option.

Instead, use the mongoreplay tool to capture, replay, and analyze commands sent to your MongoDB deployment.

validate operation changes

Starting from MongoDB 3.6, a validate operation forcibly triggers a checkpoint and flushes all in-memory data to disk only before executing a validation for disk data.

Prior to MongoDB 3.6, a checkpoint is forcibly triggered regardless of the used validation mode.

When using the validate command or the db.collection.validate() method, explicitly specify {full: true} to perform a full validation.

Index name limits

Starting from MongoDB 3.6:

• You cannot specify * as the index name during index creation.

• You cannot use index keys to delete indexes named *. Use the index name * to delete the indexes instead.

Before upgrading to MongoDB 3.6, you must:

• Delete indexes: Manually delete all existing indexes named *.

• Rename indexes: To keep the indexes, delete them and rebuild them with new names.

Deprecated options

Changes in MongoDB 3.6.1:

• Deprecate the snapshot query option.

  • MMAPv1 storage engine: Use hint({ _id: 1 }) instead to ensure that documents are not returned multiple times during a query even though intermediate writes cause documents to be moved.

  • Other storage engines (such as WiredTiger): Use hint({ $natural: 1 }) instead.

• Deprecate the $isolated operator.

  • Alternative: Use transactions or adjust read concern levels to achieve isolation.