Alterações de compatibilidade no MongoDB 9.0

Nomes de campos vazios em $group

A partir do MongoDB 9.0, o estágio $group retorna um erro se uma expressão acumulador tiver um nome de campo vazio. Para obter detalhes, consulte Restrição de $group de nome de campo vazio.

allowPartialResults na chave $queryStats agregada

A partir do MongoDB 9.0, a chave $queryStats para comandos aggregate inclui a opção allowPartialResults quando a opção é explicitamente definida. As estatísticas de query podem então distinguir entre solicitações em que allowPartialResults é omitido, explicitamente true ou explicitamente false.

A adição altera a serialização key e keyHash para queries aggregate que definem allowPartialResults. O queryShapeHash permanece inalterado. Os consumidores downstream que correspondem a keyHash podem observar valores diferentes para essas queries.

Para obter mais informações,consulte a forma de query do comando agregado.

Comparações de nulos em caminhos pontilhados que atravessam arrays

A partir do MongoDB 9.0, um caminho pontilhado que não resulta em um valor não nulo, é avaliado como null. O novo comportamento se aplica quando um campo no caminho contém uma array vazia, uma array de valores escalares ou uma array que contém uma array agrupada. Em versões anteriores, esses caminhos não eram avaliados como null, o que produzia resultados inconsistentes com $exists.

Considere uma collection que contenha os seguintes documento:

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

O caminho a.b não resulta em um valor não nulo em nenhum dos documento. A partir do MongoDB 9.0, a query { "a.b": null } corresponde a ambos os documentos. Nas versões anteriores, a query não correspondia a nenhum dos documento. A query { "a.b": { $ne: null } } retorna os resultados opostos: no MongoDB 9.0, a query não corresponde a nenhum dos documento e, em versões anteriores, correspondeu a ambos.

O MongoDB não atravessa arrays aninhadas, portanto, um elemento que é ele mesmo uma array nunca resolve o resto do caminho. Considere uma coleta que contenha os seguintes documentos:

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

Cada valor b em _id: 3 e o valor b de 2 em _id: 4 estão dentro de uma array aninhada, então o caminho a.b não os alcança. A partir do MongoDB 9.0, a query { "a.b": null } corresponde a ambos os documentos, e a query { "a.b": { $ne: null } } não corresponde a nenhum dos dois. Nas versões anteriores, a query { "a.b": null } não correspondia a nenhum dos documento. A array agrupada faz com que _id: 4 corresponda a { "a.b": null } mesmo que seu segundo elemento resolva a.b para o valor não nulo 3.

O novo comportamento afeta as comparações com null que usam os operadores $eq, $ne, $in, $nin, $gte e $lte. A correspondência de igualdade no estágio $lookup segue a mesma semântica.

As consultas falham quando um campo indexado se torna multichave

A partir do MongoDB 9.0, se um campo indexado se tornar um campo de várias chaves enquanto uma query que faz referência ao campo estiver em execução, a query poderá falhar com um QueryKilledError. Um campo indexado se torna multichave quando você insere ou atualiza um documento para que o campo contenha um valor de array.

Se sua query falhar com esse erro, execute novamente a query após a conclusão da operação de inserção ou atualização.

Os fluxos de alterações impõem a read preference após as eleições

A partir do MongoDB 9.0, um change stream aberto com readPreference de primary ou secondary retorna o erro retomável InterruptedDueToReplStateChange (código de erro 11602) de getMore se um conjunto de réplicas A eleição altera a função do nó para que ele não satisfaça mais a preferência de leitura. Nas versões anteriores, o cursor retornava resultados do mesmo nó.

Drivers compatíveis e mongos são retomados automaticamente a partir do último token de currículo. Os loops getMore manuais e mongosh devem ser retomados com resumeAfter. Para obter detalhes, consulte Retomar um fluxo de alterações.

Códigos de erro de extração da chave de índice geoespacial

A partir do MongoDB 9.0, 2dsphere as falhas de extração de chave de índice retornam os códigos de erro nomeados 510 (GeoKeyExtractionFailed) e 511 (GeoKeyExtractionFailedTimeseries). Esses códigos substituem os códigos de afirmação anteriores 16755 e 16756 para índices regulares de 2dsphere e 183934 e 183493 para coleções de séries temporais. Se a sua aplicação corresponder aos códigos anteriores, atualize-a para corresponder 510 e 511.

Bloqueios de coleção mais fortes para vários bancos de dados renameCollection

A partir do MongoDB 9.0, quando você renomeia uma collection entre diferentes bancos de dados em um conjunto de réplicas, o comando renameCollection mantém um bloqueio exclusivo nas collections de origem e destino. A bloqueio dura por toda a operação e bloqueia operações e gravações em DDL em ambas as coleções. A maioria das operações de leitura usa leituras sem bloqueio e não é bloqueada.

As versões anteriores liberaram o bloqueio da coleção de origem antes de renameCollection concluir a renomeação. Uma gravação simultânea na coleção de origem durante essa janela pode ser perdida.

A alteração afeta apenas conjuntos de réplicas. Os clusters fragmentados já bloqueio ambas as coleções durante a renomeação.

Uso de data das operações de JavaScript no lado do servidor UTC

A partir do MongoDB 9.0, o JavaScript do lado do servidor é executado em um mecanismo baseado em WebAssembling (WASM) que avalia as operações Date locais em UTC, independentemente do zona horário do host mongod. Em versões anteriores, essas operações observavam o zona horário do host. A alteração afeta o JavaScript executado em $function,$accumulator,$where e mapReduce.

O valor de data BSON armazenado não é alterado, assim como as operações UTC, como Date.prototype.getTime(), Date.prototype.toISOString() e os métodos getUTC*(). A diferença afeta as operações de horário local:

• Date.prototype.toString()

• Date.prototype.toTimeString()

• Date.prototype.getHours() e outros getters locais

• Construtores e configuradores de Date locais

• Operações que convertem implicitamente datas em strings, incluindo Array.prototype.sort() chamado sem um comparador

Considere as seguintes operações em um mongod que é executado com 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"
      }
   }
} )

Em versões anteriores, 13:30 UTC é 08:30 em Nova York, então getHours() retorna 8 e a query corresponde ao documento. Começando no MongoDB 9.0, getHours() retorna 13 e a query não corresponde. A operação é bem-sucedida em ambas as versões porque a data armazenada permanece válida, portanto a diferença não é relatada como erro. As implementações que executam versões binárias mistas podem retornar resultados diferentes para o mesmo JavaScript.

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

JavaScript do lado do servidor indisponível em ppc64le

A partir do MongoDB 9.0, o JavaScript do lado do servidor não está disponível na arquitetura ppc64le. Os binários mongod e mongos para ppc64le não incluem um mecanismo JavaScript. Como resultado, as operações$function, $accumulator, $where e mapReduce falham nessa arquitetura. As versões anteriores executaram estas operações em ppc64le.

Você não pode habilitar o JavaScript do lado do servidor em ppc64le com uma definição de arquivo de configuração ou uma opção de linha de comando.

Prefixo, sufixo e pré-visualização pública de substring do Queryable Encryption para migração GA

MongoDB 9.0 marca o GA de queries de prefixo, sufixo e substring em campos de string criptografados em coleções habilitadas para Queryable Encryption . O recurso GA é incompatível com a versão Public Preview lançada no MongoDB 8.2, que não deve ser usado agora que o recurso está GA.

Para usar queries de prefixo, sufixo ou substring com Queryable Encryption, o MongoDB deve ser da versão 9.0 ou posterior, com drivers compatíveis com 9.0. Se você ainda estiver usando a visualização pública, o MongoDB deverá permanecer na versão 8.2 ou 8.3, com drivers compatíveis com 8.2 ou 8.3.

Os drivers do MongoDB 9.0 podem descriptografar dados criados com os drivers do MongoDB 8.2 ou 8.3. Para opções de atualização, consulte as seções a seguir.

Expressões em Visualizações

No MongoDB 9.0, $convert podem converter um objeto para binData. Para detalhes, consulte Converter um objeto em binData.

Se você criar uma visualização que use essa conversão, as queries nessa visualização retornarão um erro após o downgrade para uma versão anterior.

Antes de fazer o downgrade de 9.0, atualize ou elimine quaisquer visualizações que usem essa conversão.