Cambios de compatibilidad en MongoDB 9.0

Nombres de campos vacíos en $group

A partir de MongoDB 9.0, la etapa $group devuelve un error si una expresión acumuladora tiene un nombre de campo vacío. Para obtener más información, consulte Restricción de $group para nombres de campo vacíos.

allowPartialResults en conjunto $queryStats Clave

A partir de MongoDB 9.0, la clave $queryStats para los comandos aggregate incluye la opción allowPartialResults cuando esta se establece explícitamente. De esta forma, las estadísticas de consulta pueden distinguir entre las solicitudes en las que se omite allowPartialResults, se especifica explícitamente true o se especifica explícitamente false.

La adición modifica la serialización de key y keyHash para las consultas aggregate que establecen allowPartialResults. queryShapeHash permanece sin cambios. Los consumidores posteriores que coincidan con keyHash podrían observar valores diferentes para estas consultas.

Para obtener más información,consulte la forma de consulta del comando aggregate.

Comparaciones nulas en rutas punteadas que recorren matrices

A partir de MongoDB 9.0, una ruta con puntos que no se resuelve en un valor no nulo se evalúa como null. Este nuevo comportamiento se aplica cuando un campo de la ruta contiene un array vacío, un array de valores escalares o un array que contiene un array anidado. En versiones anteriores, estas rutas no se evaluaban como null, lo que producía resultados que no coincidían con $exists.

Considera una colección que contiene los siguientes documentos:

{ _id: 1, a: [ 1 ] }
{ _id: 2, a: [ ] }

La ruta a.b no se resuelve en un valor no nulo en ninguno de los documentos. A partir de MongoDB 9.0, la consulta { "a.b": null } coincide con ambos documentos. En versiones anteriores, la consulta no coincidía con ninguno. La consulta { "a.b": { $ne: null } } devuelve los resultados opuestos: en MongoDB 9.0, la consulta no coincide con ninguno de los documentos, mientras que en versiones anteriores sí coincidía con ambos.

MongoDB no recorre matrices anidadas, por lo que un elemento que es a su vez una matriz nunca resuelve el resto de la ruta. Considere una colección que contiene los siguientes documentos:

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

Cada valor b en _id: 3 y el valor b de 2 en _id: 4 se encuentran dentro de un array anidado, por lo que la ruta a.b no los alcanza. A partir de MongoDB 9.0, la consulta { "a.b": null } coincide con ambos documentos, y la consulta { "a.b": { $ne: null } } no coincide con ninguno. En versiones anteriores, la consulta { "a.b": null } no coincidía con ninguno de los documentos. El array anidado hace que _id: 4 coincida con { "a.b": null } aunque su segundo elemento resuelve a.b al valor no nulo 3.

El nuevo comportamiento afecta a las comparaciones con null que utilizan los operadores $eq, $ne, $in, $nin, $gte y $lte. La comparación de igualdad en la etapa $lookup sigue la misma semántica.

Las consultas fallan cuando un campo indexado se convierte en multiclave.

A partir de MongoDB 9.0, si un campo indexado se convierte en un campo de clave múltiple mientras se ejecuta una consulta que hace referencia a dicho campo, la consulta podría fallar con un QueryKilledError. Un campo indexado se convierte en clave múltiple cuando se inserta o actualiza un documento, de modo que el campo contiene un valor de matriz.

Si su consulta falla con este error, vuelva a ejecutarla una vez que se complete la operación de inserción o actualización.

Modificar las transmisiones: Aplicar la preferencia de lectura después de las elecciones

A partir de MongoDB 9.0, un flujo de cambios abierto con un readPreference de primary o secondary devuelve el error reanudable InterruptedDueToReplStateChange (código de error 11602) de getMore si una elección de conjunto de réplicas cambia el rol del nodo de modo que ya no satisface la preferencia de lectura. En versiones anteriores, el cursor seguía devolviendo resultados del mismo nodo.

Los controladores compatibles y mongos se reanudan automáticamente desde el último token de reanudación. Los bucles manuales getMore y mongosh deben reanudarse con resumeAfter. Para obtener más información, consulte Reanudar un flujo de cambios.

Códigos de error de extracción de claves del índice geoespacial

A partir de MongoDB 9.0, los fallos en la extracción de claves de índices2dsphere devuelven los códigos de error 510 (GeoKeyExtractionFailed) y 511 (GeoKeyExtractionFailedTimeseries). Estos códigos reemplazan los códigos de aserción anteriores 16755 y 16756 para índices 2dsphere regulares y 183934 y 183493 para colecciones de series temporales. Si su aplicación coincide con los códigos anteriores, actualícela para que coincida con 510 y 511.

Bloqueos de colección más robustos para bases de datos cruzadas renameCollection

A partir de MongoDB 9.0, al renombrar una colección entre bases de datos distintas en un conjunto de réplicas, el comando renameCollection mantiene un bloqueo exclusivo sobre las colecciones de origen y destino. El bloqueo dura toda la operación y bloquea las operaciones DDL y las escrituras en ambas colecciones. La mayoría de las operaciones de lectura utilizan lecturas sin bloqueo y no se ven bloqueadas.

Las versiones anteriores liberaban el bloqueo de la colección de origen antes de que renameCollection completara el cambio de nombre. Una escritura simultánea en la colección de origen durante ese lapso podía perderse.

El cambio afecta únicamente a los conjuntos de réplicas. Los clústeres fragmentados ya bloquean ambas colecciones durante el tiempo que dure el cambio de nombre.

Las operaciones de fecha con JavaScript del lado del servidor utilizan UTC.

A partir de MongoDB 9.0, JavaScript del lado del servidor se ejecuta en un motor basado en WebAssembly (WASM) que evalúa las operaciones locales Date en UTC, independientemente de la zona horaria del host mongod. En versiones anteriores, estas operaciones respetaban la zona horaria del host. El cambio afecta a JavaScript que se ejecuta en $function,$accumulator,$where y mapReduce.

El valor de fecha BSON almacenado no cambia, al igual que las operaciones UTC como Date.prototype.getTime(), Date.prototype.toISOString() y los métodos getUTC*(). La diferencia afecta a las operaciones de tiempo local:

• Date.prototype.toString()

• Date.prototype.toTimeString()

• Date.prototype.getHours() y otros recolectores locales

• Constructores y métodos de configuración locales Date

• Operaciones que convierten implícitamente fechas a cadenas, incluyendo Array.prototype.sort() llamadas sin un comparador.

Considere las siguientes operaciones en un mongod que se ejecuta con TZ=America/New_York:

db.events.insertOne( {
   name: "before-opening",
   occurredAt: ISODate("2024-01-15T13:30:00Z")
} )
db.events.find( {
   $expr: {
      $function: {
         body: function(date) { return date.getHours() < 9; },
         args: [ "$occurredAt" ],
         lang: "js"
      }
   }
} )

En versiones anteriores, 13:30 UTC es 08:30 en Nueva York, por lo que getHours() devuelve 8 y la consulta coincide con el documento. A partir de MongoDB, 9.0, getHours() devuelve 13 y la consulta no coincide. La operación se realiza correctamente en ambas versiones porque la fecha almacenada sigue siendo válida, por lo que la diferencia no se informa como un error. Las implementaciones que ejecutan versiones binarias mixtas pueden devolver resultados diferentes para el mismo JavaScript.

db.events.find( {
   $expr: {
      $lt: [ { $hour: { date: "$occurredAt",
                        timezone: "America/New_York" } }, 9 ]
   }
} )

JavaScript del lado del servidor no está disponible en ppc64le

A partir de MongoDB 9.0, JavaScript del lado del servidor no está disponible en la arquitectura ppc64le. Los binarios mongod y mongos para ppc64le no incluyen un motor JavaScript. Como resultado, las operaciones$function, $accumulator, $where y mapReduce fallan en esa arquitectura. Las versiones anteriores ejecutaban estas operaciones en ppc64le.

No se puede habilitar JavaScript del lado del servidor en ppc64le con una configuración de archivo de configuración o una opción de línea de comandos.

Prefijo, sufijo y subcadena de cifrado consultables: vista previa pública para migración a disponibilidad general.

MongoDB 9.0 marca la disponibilidad general (GA) de las consultas de prefijo, sufijo y subcadena en campos de cadena cifrados en colecciones habilitadas para el cifrado consultable. Esta función de disponibilidad general es incompatible con la versión de vista previa pública lanzada en MongoDB 8.2, que no debe usarse ahora que la función está disponible.

Para usar consultas de prefijo, sufijo o subcadena con Cifrado Consultable, MongoDB debe ser la versión 9.0 o posterior, con controladores compatibles con 9.0. Si aún usa la Vista Previa Pública, MongoDB debe permanecer en la versión 8.2 o 8.3, con controladores compatibles con 8.2 o 8.3.

Los controladores MongoDB 9.0 pueden descifrar datos creados con los controladores MongoDB 8.2 o 8.3. Para conocer las opciones de actualización, consulte las siguientes secciones.

Expresiones en Vistas

En MongoDB, 9, 0 y$convert pueden convertir un objeto a binData. Para obtener más información, consulte Convertir un objeto a binData.

Si crea una vista que utilice esta conversión, las consultas sobre esa vista devolverán un error después de volver a una versión anterior.

Antes de degradar desde 9.0, actualice o elimine cualquier vista que utilice esta conversión.