Menu Docs
Página inicial do Docs
/
Manual do MongoDB
/ /

update Evento

Nesta página

  • Resumo
  • Descrição
  • Comportamento
  • Documentar pré e pós-imagens
  • Desambiguação de Caminho
  • Exemplo
update

Um evento update ocorre quando uma operação atualiza um documento em uma coleção.

Observação

Desambiguação

Para saber mais sobre eventos que ocorrem quando as opções de coleta são modificadas, consulte o evento modify .

Campo
Tipo
Descrição
_id
Documento

Um objeto BSON que serve como um identificador para o evento de fluxo de alterações. Este valor é utilizado como resumeToken para o parâmetro resumeAfter ao retomar um fluxo de alteração. O objeto _id tem o seguinte formulário:

{
"_data" : <BinData|hex string>
}

O tipo de _data depende das versões do MongoDB e, em alguns casos, da versão de compatibilidade de recursos (fCV) no momento da abertura ou retomada do fluxo de alterações. Consulte Tokens de currículo para obter a lista completa de _data tipos.

Para obter um exemplo de como retomar um fluxo de alterações por resumeToken, consulte Retomar um fluxo de alterações.

clusterTime
Timestamp

O carimbo de data/hora da entrada de registro opcional associada ao evento.

Todas as notificações de eventos do fluxo de alterações associadas a uma transação com vários documentos têm o mesmo valor clusterTime: a hora em que a transação foi confirmada.

Eventos com o mesmo clusterTime podem não estar relacionados à mesma transação. Alguns eventos não estão nem um pouco relacionados a uma transação. A partir do MongoDB 8.0, isso pode ser verdade para eventos em qualquer sistema. Nas versões anteriores, este comportamento era possível apenas para eventos em um cluster fragmentado.

Para identificar eventos para uma única transação, você pode usar a combinação de lsid e txnNumber no documento de eventos do fluxo de alterações.

Alterado na versão 8.0.

collectionUUID
UUID

UUID identificando a coleção onde ocorreu a alteração.

Novidades na versão 6.0.

documentKey
documento

Documento que contém o valor _id do documento criado ou modificado pela operação CRUD.

Para coleções fragmentadas, este campo também exibe a chave de fragmentação completa do documento. O campo _id não se repete se já fizer parte da chave fragmentada.

fullDocument
documento

O documento criado ou modificado por uma operação CRUD.

Este campo aparece somente se você configurou o fluxo de alteração com fullDocument configurado para updateLookup. Quando você configura o fluxo de alterações com updateLookup, o campo representa a versão atual confirmada pela maioria do documento modificada pela operação de atualização. O documento pode ser diferente das alterações descritas em updateDescription se quaisquer outras operações confirmadas pela maioria tiverem modificado o documento entre a operação de atualização original e a pesquisa completa do documento.

Para mais informações, consulte Pesquisar documento completo para atualizar operações.

Alterado na versão 6.0.

A partir do MongoDB 6.0, se você definir a opção changeStreamPreAndPostImages usando db.createCollection(), create ou collMod, o campo fullDocument mostrará o documento depois que ele foi inserido, substituído ou atualizado (o documento pós-imagem). fullDocument é sempre incluído para eventos insert.

fullDocumentBeforeChange
documento

O documento antes das alterações serem aplicadas pela operação. Ou seja, a pré-imagem do documento.

Este campo está disponível quando você habilita o campo changeStreamPreAndPostImages para uma coleção utilizando o método db.createCollection() ou os comandos create ou collMod.

Novidades na versão 6.0.

lsid
documento

O identificador da sessão associada à transação.

Somente presente se a operação fizer parte de uma transação de vários documentos.

ns
documento

O namespace (banco de dados e/ou coleção) afetado pelo evento.

ns.coll
string

O nome da coleção onde o evento ocorreu.

ns.db
string

O nome do banco de dados onde ocorreu o evento.

operationType
string

O tipo de operação que os relatórios de notificação de alteração.

Retorna um valor de update para estes eventos de alteração.

updateDescription
documento

Um documento que descreve os campos que foram atualizados ou removidos pela operação de atualização.

updateDescription.
disambiguatedPaths
documento

Um documento que fornece esclarecimento dos descritores de campo ambíguos em updateDescription.

Quando o evento de alteração update descreve alterações em um campo em que o caminho contém um ponto (.) ou em que o caminho inclui um subcampo numérico sem array, o campo disambiguatedPath fornece um documento com uma array que lista cada entrada no caminho para o campo modificado.

Exige que você configure a opção showExpandedEvents para true.

Novidades na versão 6.1.

updateDescription.
removedFields
array

Uma array de campos que foram removidos pela operação de atualização.

updateDescription.
truncatedArrays
array

Uma array de documentos que registram truncamentos de array executados com atualizações baseadas em pipelin usando uma ou mais das seguintes etapas:

Observação

Se toda a array for substituída, as truncações serão reportadas em updateDescription.updatedFields.

updateDescription.
truncatedArrays.
field
string

O nome do campo truncado.

updateDescription.
truncatedArrays.
newSize
inteiro

O número de elementos na array truncada.

updateDescription.
updatedFields
documento

Um documento cujas chaves correspondem aos campos que foram modificados pela operação de atualização. O valor de cada campo corresponde ao novo valor desses campos, em vez da operação que resultou no novo valor.

txnNumber
Número longo

Juntamente com o lsid, um número que ajuda a identificar exclusivamente uma transação.

Somente presente se a operação fizer parte de uma transação de vários documentos.

wallTime

A data e hora do servidor da operação do banco de dados. wallTime difere de clusterTime em que clusterTime é um carimbo de data/hora obtido da entrada oplog associada ao evento de operação do banco de dados.

Novidades na versão 6.0.

A partir do MongoDB 6.0, você verá um documento fullDocumentBeforeChange com os campos antes de o documento ser alterado (ou excluído) se executar estas etapas:

  1. Ative o novo campo changeStreamPreAndPostImages para uma coleção utilizando db.createCollection(), create ou collMod.

  2. Configure fullDocumentBeforeChange para "required" ou "whenAvailable" em db.collection.watch().

Exemplo de documento fullDocumentBeforeChange na saída do fluxo de mudança:

"fullDocumentBeforeChange" : {
"_id" : ObjectId("599af247bb69cd89961c986d"),
"userName" : "alice123",
"name" : "Alice Smith"
}

Para obter exemplos completos com a saída do fluxo de alterações, consulte Fluxos de alterações com imagens pré e pós-documento.

As imagens pré e pós não estarão disponíveis para um change stream se as imagens forem:

  • Não habilitadas na coleção no momento de uma operação de atualização ou exclusão de documento.

  • Removido após o tempo de retenção pré e pós-imagem definido em expireAfterSeconds.

    • O exemplo a seguir define expireAfterSeconds para 100 segundos em um cluster inteiro:

      use admin
      db.runCommand( {
      setClusterParameter:
      { changeStreamOptions: {
      preAndPostImages: { expireAfterSeconds: 100 }
      } }
      } )
    • O exemplo a seguir retorna as configurações atuais do changeStreamOptions, incluindo expireAfterSeconds:

      db.adminCommand( { getClusterParameter: "changeStreamOptions" } )
    • Definir expireAfterSeconds para off usa a política de retenção: pré-imagens e pós-imagens são retidas até os eventos de change streams serem removidos do oplog.

    • Se um change stream for removido do oplog, as imagens pré e pós correspondentes também serão excluídas, independentemente do tempo de retenção pré e pós-imagem expireAfterSeconds .

Considerações adicionais:

  • Habilitar pré e pós-imagens consome espaço de armazenamento e adiciona tempo de processamento. Ative as imagens anteriores e posteriores somente se precisar delas.

  • Limite o tamanho do evento de transmissão da alteração para menos de 16 megabytes. Para limitar o tamanho do evento, você pode:

    • Limite o tamanho do documento a 8 megabytes. Você pode solicitar imagens pré e pós simultaneamente na saída do change stream se outros campos de evento de change stream, como updateDescription não forem grandes.

    • Solicite apenas pós-imagens na saída de fluxo de alteração para documentos de até 16 megabytes se outros campos de evento de fluxo de alteração como updateDescription não forem grandes.

    • Solicite somente pré-imagens na saída do change stream para documentos de até 16 megabytes se:

      • as atualizações do documento afetam apenas uma pequena fração da estrutura ou conteúdo do documento, e

      • não causa um evento de alteração replace . Um evento replace sempre inclui o pós-imagem.

  • Para solicitar uma pré-imagem, defina fullDocumentBeforeChange como required ou whenAvailable em db.collection.watch(). Para solicitar uma pós-imagem, defina fullDocument usando o mesmo método.

  • As pré-imagens são escritas na coleção config.system.preimages .

    • A coleção config.system.preimages pode ficar grande. Para limitar o tamanho da coleção, você pode definir expireAfterSeconds tempo para as pré-imagens, conforme mostrado anteriormente.

    • As pré-imagens são removidas de forma assíncrona por um processo de plano de fundo.

Importante

Funcionalidade incompatível com versões anteriores

A partir do MongoDB 6.0, se você estiver usando imagens anteriores e posteriores de documentos para change streams, deverá desabilitar changeStreamPreandPostImages para cada coleção usando o collMod comando antes de poder fazer o downgrade para uma versão anterior do MongoDB.

Dica

Veja também:

Novidades na versão 6.1.

O campo updateDescription observa alterações feitas em campos específicos em documentos por uma operação. Estes descritores de campo utilizam pontos (.) como separadores de caminho e números como índices de array, o que leva a alguma ambiguidade quando contém nomes de campo que utilizam pontos ou números.

Quando um evento do update relata alterações envolvendo campos ambíguos, o documento do disambiguatedPaths fornece a chave de caminho com uma array listando cada componente de caminho.

Observação

O campo disambiguatedPaths só está disponível em fluxos de alteração iniciados com a opção showExpandedEvents

Por exemplo, considere um documento que relacione as pessoas e as cidades em que vivem:

{
"name": "Anthony Trollope",
"home.town": "Oxford",
"residences": [
{"0": "Oxford"},
{"1": "Sunbury"}
]
}
  • Quando uma atualização modifica o campo home.town de Oxford para London, ela produz uma descrição de atualização que se parece com isto:

    "updateDescription": {
    "updatedFields": {
    "home.town": "London"
    },
    "disambiguatedPaths": {
    "home.town": [ "home.town" ]
    }
    }

    Como o campo home.town contém um período, o campo disambiguatedPaths mostra uma array com um valor, para indicar que town não é um subcampo de home.

  • Quando uma atualização modifica um valor na array residences para fazer a mesma alteração, ela produz uma descrição de atualização que se parece com isto:

    "updateDescription": {
    "updatedFields": {
    "residences.0.0": "London"
    },
    "disambiguatedPaths": { "residences.0.0": [ "residences", 0, "0" ] }
    }

    Os caminhos desambiguados incluem um número inteiro 0 para indicar o índice de array e a string "0" para indicar o nome do campo dentro do documento aninhado.

Há dois casos em que o disambiguatedPath não inclui um campo numérico:

  • Quando o primeiro campo no caminho é uma sequência numérica (ou seja, 0.name). Isto não é ambíguo, pois o primeiro campo não pode ser um índice de array.

  • Quando o campo de string numérica tiver zeros iniciais (ou seja, 0001). Isso não é ambíguo, pois um número inteiro não pode ter zeros à esquerda.

O exemplo seguinte ilustra um evento update:

{
"_id": { <Resume Token> },
"operationType": "update",
"clusterTime": <Timestamp>,
"wallTime": <ISODate>,
"ns": {
"db": "engineering",
"coll": "users"
},
"documentKey": {
"_id": ObjectId("58a4eb4a30c75625e00d2820")
},
"updateDescription": {
"updatedFields": {
"email": "alice@10gen.com"
},
"removedFields": ["phoneNumber"],
"truncatedArrays": [ {
"field" : "vacation_time",
"newSize" : 36
} ]
}
}

O exemplo seguinte ilustra um evento update para alterar fluxos abertos com a opção fullDocument : updateLookup:

{
"_id": { <Resume Token> },
"operationType": "update",
"clusterTime": <Timestamp>,
"wallTime": <ISODate>,
"ns": {
"db": "engineering",
"coll": "users"
},
"documentKey": {
"_id": ObjectId("58a4eb4a30c75625e00d2820")
},
"updateDescription": {
"updatedFields": {
"email": "alice@10gen.com"
},
"removedFields": ["phoneNumber"],
"truncatedArrays": [ {
"field" : "vacation_time",
"newSize" : 36
} ],
"disambiguatedPaths": { }
},
"fullDocument": {
"_id": ObjectId("58a4eb4a30c75625e00d2820"),
"name": "Alice",
"userName": "alice123",
"email": "alice@10gen.com",
"team": "replication"
}
}

O documento fullDocument representa a versão mais atual acordada majoritariamente do documento atualizado. O documento fullDocument pode variar do documento no momento da operação de atualização, dependendo do número de operações de intercalação confirmadas que ocorrem entre a operação de atualização e a pesquisa do documento.

Voltar

sharedCollection