:Alterações de compatibilidade no MongoDB 3.4

Para obter mais informações sobre as alterações oficiais de compatibilidade do MongoDB, consulte o site do MongoDB.

Alterações em instâncias de cluster com sharding

Compatibilidade de renomeação de coleções com a sincronização inicial

Se uma coleção usada como source de sincronização for renomeada durante a sincronização inicial, o processo é interrompido e reiniciado, evitando riscos de corrupção de dados. Para mais informações, consulte SERVER-26117.

As operações a seguir envolvem a renomeação de coleções:

• O comando renameCollection: como o método db.collection.renameCollection().

• O estágio $out em uma operação de agregação, como ao usar o método db.collection.aggregate() ou o comando aggregate com o estágio $out.

• A opção out no MapReduce, como ao usar o método db.collection.mapReduce() ou o comando mapReduce com a opção out especificada.

• O comando convertToCapped, utilizado para converter uma coleção comum em uma coleção capped.

Ao atualizar do MongoDB 3.2.11 ou versões anteriores para o 3,4, a sincronização inicial pode falhar caso encontre uma operação de renomeação de coleção.

Antes do MongoDB v3.2.11, o processo de sincronização inicial continuava ao encontrar uma operação de renomeação de coleção que poderia corromper dados. Para mais informações, consulte SERVER-4941.

Operações descontinuadas

Especificações de coleções e índices

db.createCollection( "myCappedCollection", { cappedtypo: true, size: 5242880 } )

Alterações gerais de compatibilidade

• Ajuste nos limites de namespace: a partir do MongoDB 3,4, nomes de banco de dados não suportam mais o símbolo $.

  Nota

  Antes de atualizar para o MongoDB 3,4, exclua todos os bancos de dados cujos nomes contenham $.

• Remoção do parâmetro textSearchEnabled. A partir do MongoDB 2.6, a busca de texto é ativada por padrão.

• Remoção da ferramenta mongosniff: a partir do MongoDB 3,4, o mongosniff é substituído pela ferramenta mongoreplay, que oferece recursos mais poderosos e suporta captura e análise de tráfego de rede de forma mais flexível.

• Alterações no comportamento do estágio de agregação $project: se o estágio $project retornar um documento vazio (sem campos preservados ou adicionados), um erro é reportado.

• Problemas de contagem com hints e sparse indexes: ao usar hint() especificando um sparse index para contar documentos em uma coleção (com um predicado de consulta vazio), o sparse index pode resultar em contagens imprecisas.

  db.collection.insert({ _id: 1, y: 1 } );
  db.collection.createIndex( { x: 1 }, { sparse: true } );
  
  db.collection.find().hint( { x: 1 } ).count();

  Para obter resultados de contagem corretos, não especifique um sparse index em hint() ao contar todos os documentos de uma coleção.

  db.collection.find().count();
  
  db.collection.createIndex({ y: 1 });
  db.collection.find().hint({ y: 1 }).count();

  Antes do MongoDB 3,4, os hints eram ignorados quando o uso de sparse indexes resultava em contagens incompletas.

Alterações nas permissões de funções de usuário

A partir do MongoDB 3,4, as permissões das seguintes funções integradas deixaram de se aplicar aos bancos de dados local e config:

As seguintes funções integradas possuem permissões nos bancos de dados local e config:

• clusterManager

• clusterMonitor

• backup

• restore

Recursos incompatíveis com versões anteriores

O MongoDB 3,4 introduz os seguintes recursos que armazenam dados de forma incompatível com versões anteriores. Para ativar esses recursos, defina featureCompatibilityVersion como "3.4".

• Views

• Collation e índices sem distinção entre maiúsculas e minúsculas

• Tipo decimal

• Versão de índice v2

  • Suporta collation e tipos de dados decimais.

  • Quando featureCompatibilityVersion está definido como "3.4", a versão padrão de novos índices é v2. Caso contrário, a versão padrão é v1.

Default featureCompatibilityVersion values:

• Novas implantações do MongoDB 3,4: "3.4".

• Implantações atualizadas a partir do MongoDB 3.2: "3.2" (deve ser definido manualmente como "3.4").

Antes do MongoDB 3,4, se um banco de dados contiver views, definições de collation ou índices v2, o MongoDB não consegue iniciar. Caso existam campos do tipo decimal, as operações sobre esses documentos podem falhar.

Para atualizar para o MongoDB 3,4, todos os dados incompatíveis devem ser removidos, incluindo views, índices v2 e campos decimais.

Alterações de compatibilidade de drivers

Para usar os novos recursos introduzidos no MongoDB 3,4 (como tipo decimal e collation), atualize seu driver para uma versão que suporte esses recursos.

Alterações de comportamento do $in com elemento único e do upsert

Quando uma operação upsert não encontra documentos correspondentes, ela cria um documento base para upserts com base na declaração de igualdade do predicado de consulta e, em seguida, aplica os operadores de atualização ao documento. Exemplo:

db.c.drop()
db.c.update( { a : 3, b: "foo" }, { $set : { c : 15 } }, { upsert : true } )
db.c.find()
{ "_id" : ObjectId("59c03009529946822d0afb8c"), "a" : 3, "b" : "foo", "c" : 15 }

Antes do MongoDB 3,4, um $in com elemento único não inicializava campos.

db.c.drop()
db.c.update( { a : { $in : [1] } }, { $addToSet : { a : 2 } }, { upsert : true } )
db.c.find()
{ "_id" : ObjectId("58bdb00eb39e8f87607e9222"), "a" : [ 2 ] }

A partir do MongoDB 3,4, um $in com elemento único é tratado como uma declaração de igualdade para upserts:

• Se um predicado de consulta incluir um $in com elemento único, os campos são inicializados como campos escalares em vez de arrays.

• A operação $addToSet do exemplo anterior falha porque operadores de array não podem ser aplicados a campos escalares.

Solução: envolva a expressão $in em $elemMatch para forçar a manutenção do tipo array dos campos.

db.c.drop()
db.c.update(
   { a : { $elemMatch : { $in : [ 2 ] } } },
   { $addToSet : { a: 3 } },
   { upsert: true } )
db.c.find()
{ "_id" : ObjectId("..."), "a" : [ 3 ] }