:Modifications de compatibilité dans MongoDB 3.6

mongod --bind_ip localhost,My-Example-Associated-Hostname

mongo --host My-Example-Associated-Hostname

mongo --host 198.51.100.1

Modifications du comportement de $type: "array"

À partir de MongoDB 3.6, les expressions type: "array" et $type: 4 correspondent aux champs de type tableau contenant des éléments de n'importe quel type.

Avant MongoDB 3.6, $type: "array" ne correspondait qu'aux champs de type tableau contenant des tableaux imbriqués.

Par exemple, une collection nommée c contient les documents suivants :

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

L'opération suivante interroge les données selon le type du champ a :

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

À partir de MongoDB 3.6, une requête $type renvoie les deux documents de la collection, car la requête détecte désormais que le champ a est un tableau.

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

Avant MongoDB 3.4, une requête $type ne renvoyait que les documents dont le champ a contenait des éléments de type tableau BSON.

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

Si votre instance actuelle exécute MongoDB 3.4.x et que vous utilisez des index partiels dont l'expression partialFilterExpression contient $type: "array" ou $type: 4, vous devez reconstruire ces index après la mise à niveau vers MongoDB 3.6 afin d'éviter les conflits dus aux changements sémantiques de $type: 'array'.

Modifications du comportement de tri des tableaux

À partir de MongoDB 3.6, lors du tri sur un champ de type tableau, MongoDB utilise l'élément du tableau ayant la valeur la plus faible pour une clé de tri ascendante et l'élément ayant la valeur la plus élevée pour une clé de tri descendante. Le tri ne tient plus compte des prédicats de requête lors de la sélection d'un élément de tableau comme clé de tri. Cette modification de comportement s'applique à la commande find et aux opérations du pipeline d'agrégation.

Par conséquent, les applications effectuant des tris sur un champ de type tableau peuvent renvoyer des résultats de tri différents.

{ _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}}])

Mises à jour des nouveaux champs

À partir de MongoDB 3.6, les champs ajoutés lors des opérations de mise à jour sont ajoutés dans l'ordre lexicographique.

Par exemple, une collection nommée coll contient le document suivant :

{ _id: 0, x: 0 }

Exécutez une opération de mise à jour pour ajouter les champs suivants :

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

Dans MongoDB 3.6, les nouveaux champs sont ajoutés dans l'ordre lexicographique. Par conséquent, le document mis à jour est {_id: 0, x: 0, a: 0, b: 0}.

Avant MongoDB 3.6, les nouveaux champs étaient ajoutés dans l'ordre de leur apparition dans le document de mise à jour. Par conséquent, le document mis à jour était {_id: 0, x: 0, b: 0, a: 0}.

Champs en conflit avec la syntaxe d'identifiant arrayFilters

À partir de MongoDB 3.6, les champs dont le nom entre en conflit avec la syntaxe d'identifiant arrayFilters (telle que $[]) ne peuvent plus être mis à jour.

Par exemple, une collection nommée coll contient le document suivant :

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

Exécutez une opération de mise à jour :

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

À partir de MongoDB 3.6, une opération de mise à jour échoue car le nom du champ $[] entre en conflit avec la syntaxe d'identifiant arrayFilters.

Validation plus stricte de l'opérateur $pop

À partir de MongoDB 3.6, les paramètres de l'opérateur $pop doivent être définis sur l'une des valeurs suivantes :

• -1 : supprime le premier élément d'un tableau, ou

• 1 : supprime le dernier élément d'un tableau.

Avant MongoDB 3.6 :

• Les nombres négatifs permettaient de supprimer le premier élément d'un tableau, ou

• Les nombres non négatifs ou les valeurs non numériques permettaient de supprimer le dernier élément d'un tableau.

Suppression de l'opérateur $pushAll

MongoDB 3.6 supprime l'opérateur $pushAll (obsolète depuis MongoDB 2.4).

Utilisez plutôt les opérateurs $push et $each. Exemple :

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

Obsolescence du mécanisme d'authentification MongoDB-CR

À partir de MongoDB 3.6, MongoDB déclare obsolète le mécanisme d'authentification MONGODB-CR. Si ce n'est pas déjà fait, mettez à niveau votre schéma d'authentification MONGODB-CR vers SCRAM.

Nœuds arbitres et leur priorité

Tous les nœuds arbitres ont une priorité fixe de 0.

Obsolescence de l'architecture de réplication maître-esclave

MongoDB 3.6 déclare officiellement obsolète l'architecture de réplication maître-esclave.

Obsolescence de l'option --nojournal pour le moteur de stockage WiredTiger

MongoDB 3.6 déclare obsolète l'option --nojournal pour les membres de replica set utilisant le moteur de stockage WiredTiger, afin d'éviter les risques liés aux données.

Ajustements de la commande aggregate et de sa sortie

À partir de MongoDB 3.6, la commande aggregate ne renvoie plus les résultats sous forme d'un seul document.

Lors de l'exécution de la commande aggregate, vous devez spécifier l'une des options suivantes :

• cursor : renvoie les résultats sous forme de curseur (adapté aux grands ensembles de données).

• explain : renvoie une analyse du plan d'exécution d'un pipeline d'agrégation.

Nous vous recommandons d'utiliser db.collection.aggregate() dans le shell mongo ou la méthode équivalente dans votre pilote. Ces méthodes renvoient un curseur par défaut, sauf si l'option explain est utilisée.

Modifications de la conversion des champs de date en chaînes dans les expressions d'agrégation

À partir de MongoDB 3.6, MongoDB convertit systématiquement une date en une chaîne contenant une précision en millisecondes et se terminant par la lettre 'Z' (indiquant le fuseau horaire UTC) dans une expression d'agrégation.

Exemple :

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

Avant MongoDB 3.6, les champs de données des deux documents étaient renvoyés sous forme de chaînes au format "2017-10-18t20:04:27" et "2017-10-18t20:04:28".

À partir de MongoDB 3.6, les champs de données des deux documents sont renvoyés sous forme de chaînes au format "2017-10-18t20:04:27.978z" et "2017-10-18t20:04:28.192z" (incluant les millisecondes et la lettre 'z' en minuscule).

Les modifications s'appliquent aux opérateurs d'agrégation suivants :

• $concat

• $substr

• $substrBytes

• $substrCP

• $strcasecmp

• $toLower

• $toUpper

Suppression des commandes et options de diagnostic des journaux

MongoDB 3.6 supprime les options obsolètes diagLogging et mongod --diaglog.

Utilisez plutôt l'outil mongoreplay pour capturer, rejouer et analyser les commandes envoyées à votre déploiement MongoDB.

Modifications de l'opération validate

À partir de MongoDB 3.6, une opération validate déclenche systématiquement un point de contrôle et vide toutes les données en mémoire sur le disque uniquement avant d'exécuter une validation des données sur le disque.

Avant MongoDB 3.6, un point de contrôle était systématiquement déclenché, quel que soit le mode de validation utilisé.

Lorsque vous utilisez la commande validate ou la méthode db.collection.validate(), spécifiez explicitement {full: true} pour effectuer une validation complète.

Limites des noms d'index

À partir de MongoDB 3.6 :

• Vous ne pouvez pas spécifier * comme nom d'index lors de la création d'un index.

• Vous ne pouvez pas utiliser les clés d'index pour supprimer les index nommés *. Utilisez plutôt le nom d'index * pour supprimer les index.

Avant la mise à niveau vers MongoDB 3.6, vous devez :

• Supprimer les index : supprimez manuellement tous les index existants nommés *.

• Renommer les index : pour conserver les index, supprimez-les et recréez-les avec de nouveaux noms.

Options obsolètes

Modifications dans MongoDB 3.6.1 :

• Obsolescence de l'option de requête snapshot.

  • Moteur de stockage MMAPv1 : utilisez plutôt hint({ _id: 1 }) pour garantir que les documents ne sont pas renvoyés plusieurs fois lors d'une requête, même si des écritures intermédiaires provoquent le déplacement des documents.

  • Autres moteurs de stockage (tels que WiredTiger) : utilisez plutôt hint({ $natural: 1 }).

• Obsolescence de l'opérateur $isolated.

  • Alternative : utilisez des transactions ou ajustez les niveaux de read concern pour obtenir l'isolation.