Alterações de compatibilidade no MongoDB 4.4

Diretório de rollback

A partir de Mongo 4.4, o diretório de reversão de uma coleção é nomeado em homenagem ao UUID da coleção em vez do espaço de nomes da coleção; por exemplo

<dbpath>/rollback/20f74796-d5ea-42f5-8c95-f79b39bad190/removed.2020-02-19T04-57-11.0.bson

Para obter detalhes, consulte Dados de reversão.

replSetGetStatus Alterações no campo de saída

O comando replSetGetStatus e seu ajudante de shell mongo rs.status() remove os seguintes campos obsoletos de sua saída:

Alterações no documento de configuração de réplica

MongoDB 4.4 adiciona o campo term ao documento de configuração do conjunto de réplicas. Os membros do conjunto de réplica utilizam term e version para obter consenso sobre a configuração de réplica "mais recente". Definindo featureCompatibilityVersion (fCV) : "4.4" executa implicitamente um replSetReconfig para adicionar o campo term ao documento de configuração e bloqueia até que a nova configuração se propague para a maioria dos membros do conjunto de réplicas. Da mesma forma, o downgrade para fCV : "4.2" executa implicitamente uma reconfiguração para remover o campo term .

Restrições de sincronização inicial nas operações

Para executar em um membro do conjunto de réplicas, as operações a seguir exigem que o membro esteja no estado PRIMARY ou SECONDARY .

• listDatabases

• listCollections

• listIndexes

• distinct

• dbStats

• collStats

Se o membro estiver em outro estado, como STARTUP2, os erros de operação.

Valores de getLastErrorDefaults personalizados obsoletos

A partir da versão 4.4, o MongoDB descontinua a especificação de um valor settings.getLastErrorDefaults diferente do padrão de { w: 1, wtimeout: 0 }. MongoDB 4.4 honra qualquer valor de write concern que você especificar, no entanto, as versões futuras do MongoDB podem não honrar valores diferentes do padrão. Em vez disso, use o comando setDefaultRWConcern para definir a configuração padrão de preocupação com leitura ou gravação para um conjunto de réplicas ou cluster fragmentado.

Definir campos para novos valores

A partir do MongoDB 4.4, find e projeção findAndModify() podem aceitar expressões de aggregation e sintaxe de aggregation.

Com o uso de expressões de agregação e sintaxe, incluindo o uso de literais e variáveis de agregação, se você especificar um literal (distinto de um número ou de um booleano) para o valor do campo de projeção, o campo será projetado com o novo valor.

Por exemplo, considere um inventário de collection com documentos que contêm um campo status :

db.inventory.insertOne( { _id: 1, item: "postcard", status: "A", instock: [ { warehouse: "B", qty: 15 }, { warehouse: "C", qty: 35 } ] })

A partir do MongoDB, 4.4, a operação a seguir projeta os campos status e instock com novos valores em vez de seu valor atual:

db.inventory.find(
   { status: "A" },
   { status: "Active", instock: ["blue", "crimson"] }
)

Ou seja, a operação retorna o seguinte documento:

{ "_id" : 1, "status" : "Active", "instock" : [ "blue", "crimson" ] }

Em versões anteriores, qualquer valor de especificação (com exceção do valor zero/falso ou do valor de documento anteriormente não suportado) é tratado como true para indicar a inclusão do campo com seu valor atual. Ou seja, em versões anteriores, a operação anterior retorna um documento com os campos status e instock com seus valores atuais:

{ "_id" : 1, "status" : "A", "instock" : [ { "warehouse" : "B", "qty" : 15 }, { "warehouse" : "C", "qty" : 35 } ] }

$elemMatch Ordem do campo de projeção

Independentemente da ordenação dos campos no documento, a projeção $elemMatch de um campo existente retorna o campo após as outras inclusões de campo existentes.

Por exemplo, considere uma collection players com o seguinte documento:

db.players.insertOne( {
   name: "player1",
   games: [ { game: "abc", score: 8 }, { game: "xyz", score: 5 } ],
   joined: new Date("2020-01-01"),
   lastLogin: new Date("2020-05-01")
} )

A projeção a seguir retorna o campo games após os outros campos existentes incluídos na projeção, mesmo que, no documento, o campo esteja listado antes dos campos joined e lastLogin :

db.players.find( {}, { games: { $elemMatch: { score: { $gt: 5 } } }, joined: 1, lastLogin: 1 } )

Ou seja, a operação retorna o seguinte documento:

{
   "_id" : ObjectId("5edef64a1c099fff6b033977"),
   "joined" : ISODate("2020-01-01T00:00:00Z"),
   "lastLogin" : ISODate("2020-05-01T00:00:00Z"),
   "games" : [ { "game" : "abc", "score" : 8 } ]
}

Na versão 4.2 e anterior, a projeção $elemMatch de um campo existente mantém a ordem no documento:

{
  "_id" : ObjectId("5edef91e76ddff7d92f118e1"),
  "games" : [ { "game" : "abc", "score" : 8 } ],
  "joined" : ISODate("2020-01-01T00:00:00Z"),
  "lastLogin" : ISODate("2020-05-01T00:00:00Z")
}

$slice da matriz incorporada

A projeção $slice de uma array em um documento agrupado não retorna mais os outros campos no documento aninhado quando a projeção faz parte de uma projeção de inclusão.

Por exemplo, considere uma collection inventory com documentos que contêm um campo size:

{ item: "socks", qty: 100, details: { colors: [ "blue", "red" ], sizes: [ "S", "M", "L"] } }

A operação a seguir projeta o campo _id (por padrão), o campo qty e o campo details apenas com a fatia especificada da array colors :

db.inventory.find( { }, { qty: 1, "details.colors": { $slice: 1 } } )

Ou seja, a operação retorna o seguinte documento:

{ "_id" : ObjectId("5ee92a6ec644acb6d13eedb1"), "qty" : 100, "details" : { "colors" : [ "blue" ] } }

Se a projeção $slice fizer parte de uma projeção de exclusão, a operação continuará retornando os outros campos no documento aninhado. Ou seja, a seguinte projeção é uma projeção de exclusão. A projeção exclui o campo _id e os elementos da array colors que estão fora da fatia especificada e retorna todos os outros campos.

db.inventory.find( { }, { _id: 0, "details.colors": { $slice: 1 } } )

{ "item" : "socks", "qty" : 100, "details" : { "colors" : [ "blue" ], "sizes" : [ "S", "M", "L" ] } }

A projeção $slice por si só é considerada uma exclusão.

Em versões anteriores, a projeção $slice também inclui os outros campos no documento agrupado, independentemente de a projeção ser uma inclusão ou uma exclusão.

Restrições de colisão de caminho

{ ..., size: { h: 10, w: 15.25, uom: "cm" }, ... }

db.inventory.find( {}, { size: 1, "size.uom": 1 } )

{ ..., instock: [ { warehouse: "A", qty: 35 }, { warehouse: "B", qty: 15 }, { warehouse: "C", qty: 35 } ], ... }

db.inventory.find( {}, { "instock": { $slice: 1 }, "instock.warehouse": 0 } )

$- Restrição de caminho do campo prefixado

A projeção e a projeção findAndModify() não podem projetar um campo que começa com $ , com exceção dos campos DBRef.

Por exemplo, a seguinte operação é inválida:

db.inventory.find( {}, { "$instock.warehouse": 0, "$item": 0, "detail.$price": 1 } )

$ Restrição de colocação do operador posicional

O operador de projeção $ só pode aparecer no final do caminho do campo, por exemplo "field.$" ou "fieldA.fieldB.$".

Por exemplo, a seguinte operação é inválida:

db.inventory.find( { }, { "instock.$.qty": 1 } )

Para resolver, remova o componente do caminho do campo que segue o operador de projeção $ .

$ Operador posicional e restrição $slice

O find e a projeção findAndModify() não podem incluir a expressão de projeção $slice como parte de uma expressão de projeção $ .

Por exemplo, a seguinte operação é inválida:

db.inventory.find( { "instock.qty": { $gt: 25 } }, { "instock.$": { $slice: 1 } } )

Nas versões anteriores, o MongoDB retorna o primeiro elemento (instock.$) na anterior instock que corresponde à condição de query, ou seja, a projeção posicional "instock.$" tem precedência e a $slice:1 não contém nenhum oplog. "instock.$": { $slice: 1 } não exclui nenhum outro campo do documento.

Restrição de projeção de nome de campo vazio

a projeção e a projeção findAndModify() não podem incluir uma projeção de um nome de campo vazio.

Por exemplo, a seguinte operação é inválida:

db.inventory.find( { }, { "": 0 } )

Nas versões anteriores, o MongoDB tratava a inclusão/exclusão do campo vazio como trataria a projeção de campos inexistentes.

Metadados de pesquisa de texto { $meta: "textScore" } requisito de query

A partir do MongoDB 4.4, você deve especificar o operador $text no predicado de query das operações db.collection.find() para usar a expressão { $meta: "textScore" } na projeção ou classificação. Por exemplo:

db.articles.find(
   { $text: { $search: "cake" } },
   { score: { $meta: "textScore" } }
);
db.articles.find(
   { $text: { $search: "cake" } },
   { score: { $meta: "textScore" } }
).sort( { score: {  $meta: "textScore" } } );

Se você não especificar o operador $text no predicado de query, a operação falhará. Por exemplo, as seguintes operações são inválidas começando no MongoDB 4.4:

db.articles.find(
   { },
   { score: { $meta: "textScore" } }
)
db.articles.find(
   { },
   { score: { $meta: "textScore" } }
).sort( { score: {  $meta: "textScore" } } );

Reduzir uma chave que contém um único valor

A partir do MongoDB 4.4, quando você executa o comando mapReduce , o MongoDB chama a função reduce independentemente de quantos valores estão contidos na chave associada.

Em versões anteriores, o MongoDB não chama a função reduce para uma chave que tenha um único valor.

Para mais informações, consulte Uso.

Alteração da saída de redução de mapa

A partir do MongoDB 4.4, mapReduce remove o campo counts de sua saída.

Em versões anteriores, o comando inclui um campo counts em sua saída. Por exemplo:

"counts" : {
   "input" : 4,
   "emit" : 4,
   "reduce" : 1,
   "output" : 2
},

Limite de emissão da função de mapa

A partir do MongoDB 4.4, a função map não restringe mais o tamanho de cada saída de emit() a metade do tamanho máximo do documento BSON do MongoDB.

Nas versões anteriores, uma única emissão só pode conter metade do tamanho máximo do documento BSONdo MongoDB

Remover compatibilidade com código JavaScript do tipo BSON com escopo

mapReduce não é mais compatível com o código JavaScript do tipo BSON obsoleto com escopo (tipo BSON 15) para suas funções. As funções map, reduce e finalize devem ser BSON tipo string (BSON tipo 2) ou BSON tipo JavaScript (BSON tipo 13). Para passar valores constantes que estarão acessíveis nas map reduce finalize funções , e , use o scope parâmetro .

O uso de código JavaScript com escopo para as funções mapReduce foi descontinuado desde a versão 4.2.1.

Remoção do valor rs getLog

A partir do MongoDB 4.4, o comando getLog não aceita mais o valor rs , pois essa categorização do tipo de mensagem foi descontinuada. Em vez disso, as mensagens de registro agora são sempre identificadas por seu componente, incluindo REPL para mensagens de replicação.

Consulte Filtrando por componente para ver exemplos de análise de registros que filtram no campo de componente.

Formato de Registro de Data/Hora

Com a transição para o registro JSON estruturado, o formato de carimbo de data/hora do ctime não é mais suportado. As seguintes opções de configuração não aceitam mais ctime como um parâmetro válido:

• systemLog.timeStampFormat

• mongod --timeStampFormat

• mongos --timeStampFormat

Use os formatos de carimbo de data/hora iso8601-local (padrão) ou iso8601-utc .

Parâmetro maxLogSizeKB

Com a transição para o registro JSON estruturado, o parâmetro de servidor maxLogSizeKB agora trunca quaisquer atributos individuais em uma entrada de registro que exceda o limite especificado. Anteriormente, esse parâmetro truncava toda a entrada de registro.

Além disso:

• maxLogSizeKB agora aceita um valor de 0, que desabilita totalmente a truncamento.

• maxLogSizeKB não aceita mais valores negativos.

Consulte truncamento de mensagem de log para obter mais informações.

db.collection.validate() Parameter change

O mongo método não aceita mais apenas um parâmetro db.collection.validate() booleano.

Ou seja, o método não aceita mais db.collection.validate(<boolean>) como uma abreviação para db.collection.validate({full: <boolean>}):

Validação completa em oplog

A partir do MongoDB 4.4, a validação completa no oplog para WiredTiger ignora a verificação mais completa. O validate.warnings inclui um aviso do comportamento.

Limpeza do MMAPv1

• O comando dbStats não retorna mais o campo MMAPv1 numExtents obsoleto.

• O comando replSetGetStatus não retorna mais o campo1 replSetGetStatus.initialSyncStatus.fetchedMissingDocs em sua saída.

• O comando fsync não aceita mais o campo1 async como uma opção.

Itens obsoletos