Gatilhos de banco de dados

Nesta página

Criar um gatilho de banco de dados (trigger)

Configuração
Detalhes do trigger
Configurações de trigger
eventType
Avançado
Alterar tipos de evento
Exemplo de gatilho de banco de dados (trigger)
Triggers suspensos
Retomar automaticamente um trigger suspenso
Retomar manualmente um trigger suspenso
Relatório de tempo de gatilho
Otimização de desempenho
Desativar a ordenação de eventos para operações de intermitência
Desativar pré-imagens em nível de collection
Usar Expressões de correspondência para limitar invocações de trigger
Usar expressões de projeto para reduzir o tamanho dos dados de entrada

Atlas Device Sync, Atlas Edge Server, Data API e HTTPS endpoints estão obsoletos. Consulte a página de descontinuação do para detalhes.

A documentação dos Triggers está sendo transferida para os docs do Atlas. Consulte a documentação dos Triggers em sua nova localização.

Gatilhos de banco de dados (triggers) permitem que você execute a lógica do lado do servidor sempre que ocorre uma alteração no banco de dados em um Cluster MongoDB Atlas vinculado. Você pode configurar triggers em collections individuais, bancos de dados inteiros e em todo um cluster.

Ao contrário dos triggers de dados SQL, que são executados no servidor de banco de dados, os triggers são executados em uma camada de computação sem servidor que é escalonada independentemente do servidor de banco de dados. Triggers chamam automaticamente Atlas Function e podem encaminhar eventos para manipuladores externos por meio do AWS EventBridge.

Use gatilhos de banco de dados para implementar interações de dados orientadas por eventos. Por exemplo, você pode atualizar automaticamente as informações em um documento quando um documento relacionado é alterado ou enviar uma solicitação para um serviço externo sempre que um novo documento é inserido.

Triggers de banco de dados usam os fluxos de alterações do MongoDB para observar alterações em tempo real em uma collection. Um fluxo de alterações é uma série de eventos de banco de dados em que cada um descreve uma operação em um documento na coleção. Seu aplicativo abre um novo fluxo de alterações para cada trigger de banco de dados criado em uma coleção.

Importante

Alterar limitações do stream

Há limites para o número total de change streams que você pode abrir em um cluster, dependendo do tamanho do cluster. Consulte limitações change stream para obter mais informações.

Não é possível definir um gatilho de banco de dados em uma instância sem servidor ou ou instância de banco de dados federado porque eles não oferecem suporte a change streams.

Você controla quais operações fazem com que um trigger seja acionado, bem como o resultado desse acionamento. Por exemplo, você pode executar uma função sempre que um campo específico de um documento for atualizado. A função pode acessar todo o evento de mudança, para que você sempre saiba o que mudou. Você também pode passar o evento de alteração para o AWS EventBridge para lidar com o evento fora do Atlas.

Os acionadores suportam expressões $match para filtrar eventos de alteração e expressões de $project para limitar os dados incluídos em cada evento.

Aviso

Nos triggers de nível de sistema e de banco de dados, é possível configurar triggers de forma a fazer com que outros triggers sejam acionados, resultando em recursão. Por exemplo, um trigger de nível de banco de dados que escreve em uma collection dentro do mesmo banco de dados, ou um registrador ou encaminhador de registros no nível do cluster que escreve registros em outro banco de dados no mesmo cluster.

Criar um gatilho de banco de dados (trigger)

Para abrir a tela de configuração do trigger de banco de dados na IU do App Services, clique em Triggers no menu de navegação esquerdo, clique em Create a Trigger e selecione a guia Database ao lado de Trigger Type.

Configure o trigger e clique em Save na parte inferior da página para adicioná-lo ao esquema de implantação atual.

Para criar um trigger de banco de dados com a App Services CLI:

Adicione um arquivo de configuração de trigger de banco de dados ao subdiretório triggers de um diretório de aplicativo local.
Implante o trigger:
```
appservices push
```

Observação

Os Atlas App Services não impõe nomes de arquivo específicos para arquivos de configuração do Trigger. No entanto, depois de importados, o Atlas App Services mudará o nome de cada arquivo de configuração para corresponder ao nome do Trigger que define, por exemplo, mytrigger.json.

Configuração

Os gatilhos de banco de dados (triggers) têm as seguintes opções de configuração:

Detalhes do trigger

Na seção Trigger Details , primeiro você seleciona o Trigger Type. Defina esse valor como Database para triggers de banco de dados.

Em seguida, você seleciona o Watch Against, com base no nível de granularidade desejado. Suas opções são:

Collection, quando ocorre uma alteração em uma coleta especificada
Database, quando ocorre uma alteração em qualquer coleção em um banco de dados específico
Deployment, quando ocorrem alterações de sistema em um cluster especificado. Se você selecionar o tipo de origem do sistema, os seguintes bancos de dados não serão observados quanto a alterações:
- Os bancos de dados admin admin, local e config
- Os bancos de dados de sincronização __realm_sync e __realm_sync_<app_id>
Importante
O tipo de fonte de nível de sistema só está disponível em níveis dedicados.

Dependendo do tipo de fonte que você está usando, as opções adicionais serão diferentes. A tabela a seguir descreve essas opções.

Tipo de fonte	Opções
Collection	Cluster Name. O nome do cluster MongoDB com o qual o trigger está associado. Database Name. O banco de dados MongoDB que contém a coleção assistida. Collection Name. A coleção MongoDB para monitorar. Opcional. Se você deixar essa opção em branco, o Tipo de Origem será alterado para "Banco de Dados". Operation Type. Os tipos de operação que fazem com que o Trigger seja acionado. Selecione os tipos de operação aos quais deseja que o trigger responda. As opções incluem: Insert Update Substituir Excluir Observação As operações de atualização executadas a partir do MongoDB Compass ou do MongoDB Atlas Data Explorer substituem completamente o documento anterior. Como resultado, operações de atualização executadas a partir desses clientes gerarão eventos de alteração Substituir em vez de eventos Atualizar. Full DocumentSe ativado, os eventos de alteração de atualização incluirão a versão mais recente aprovada pela maioria do documento modificado depois que a alteração foi aplicada no campo `fullDocument`. Observação Independentemente desta configuração, os eventos Inserir e Substituir sempre incluem o campo `fullDocument`. Eventos Excluir nunca incluem o campo `fullDocument`. Document Preimage. Quando habilitados, os eventos de alteração incluem uma cópia do documento modificado imediatamente antes de a alteração ser aplicada no `fullDocumentBeforeChange` campo . Isso tem considerações de desempenho. Todos os eventos de alteração, exceto os eventos de inserção, incluem a pré-imagem do documento.
Database	Cluster Name. O nome do cluster MongoDB com o qual o trigger está associado. Database Name. O banco de dados MongoDB a ser observado. Opcional. Se você deixar esta opção em branco, o tipo de fonte será alterado para "Sistema,", a menos que você esteja em um nível compartilhado, caso em que o App Services não permitirá que você salve o trigger. Operation Type. Os tipos de operação que fazem com que o Trigger seja acionado. Selecione os tipos de operação aos quais deseja que o trigger responda. As opções incluem: criar coleta Modificar collection Renomear coleção Descartar collection Fragmentar coleção Refragmentar collection Chave de fragmento da coleção Refine Observação As operações de atualização executadas a partir do MongoDB Compass ou do MongoDB Atlas Data Explorer substituem completamente o documento anterior. Como resultado, operações de atualização executadas a partir desses clientes gerarão eventos de alteração Substituir em vez de eventos Atualizar. Full DocumentSe ativado, os eventos de alteração de atualização incluirão a versão mais recente aprovada pela maioria do documento modificado depois que a alteração foi aplicada no campo `fullDocument`. Observação Independentemente desta configuração, os eventos Inserir e Substituir sempre incluem o campo `fullDocument`. Eventos Excluir nunca incluem o campo `fullDocument`. Document Preimage. Quando habilitados, os eventos de alteração incluem uma cópia do documento modificado imediatamente antes de a alteração ser aplicada no `fullDocumentBeforeChange` campo . Isso tem considerações de desempenho. Todos os eventos de alteração, exceto os eventos Inserir, incluem a pré-imagem do documento. Desativado para fontes de banco de dados e implantação, para limitar as observações desnecessárias no cluster para uma nova coleção sendo criada.
Deployment	Cluster Name. O nome do cluster MongoDB com o qual o trigger está associado. Operation Type. Os tipos de operação que ocorrem no cluster que fazem o trigger disparar. Selecione os tipos de operação aos quais deseja que o trigger responda. As opções incluem: Descartar banco de dados Full DocumentSe ativado, os eventos de alteração de atualização incluirão a versão mais recente aprovada pela maioria do documento modificado depois que a alteração foi aplicada no campo `fullDocument`. Observação Independentemente desta configuração, os eventos Inserir e Substituir sempre incluem o campo `fullDocument`. Eventos Excluir nunca incluem o campo `fullDocument`. Document Preimage. Quando habilitados, os eventos de alteração incluem uma cópia do documento modificado imediatamente antes de a alteração ser aplicada no `fullDocumentBeforeChange` campo . Isso tem considerações de desempenho. Todos os eventos de alteração, exceto os eventos Inserir, incluem a pré-imagem do documento. Desativado para fontes de banco de dados e implantação, para limitar as observações desnecessárias no cluster para uma nova coleção sendo criada.

Dica

Pré-imagens e otimização de desempenho

As pré-imagens exigem uma sobrecarga adicional de armazenamento que pode afetar o desempenho. Se você não estiver usando pré-imagens em uma coleção, desabilite as pré-imagens. Para saber mais, consulte Desabilitar pré-imagens em nível de coleção.

As pré-imagens de documentos são suportadas em clusters Atlas não fragmentados que executam o MongoDB 4.4+ e em clusters Atlas fragmentados que executam o MongoDB 5.3 e posterior. Você pode atualizar um cluster não fragmentado (com pré-imagens) para um cluster fragmentado, desde que o cluster esteja executando a versão 5.3 ou posterior.

Configurações de trigger

Campo	Descrição
Auto-Resume Triggers	Se ativado, quando o token de retomada desse trigger não puder ser encontrado no oplog do cluster, o trigger retomará automaticamente os eventos de processamento no próximo evento relevante de change streams. Todos os eventos de change streams, desde quando o trigger foi suspenso até que o trigger retome a execução, não têm o trigger acionado para eles.
Event Ordering	Se habilitado, os eventos de trigger são processados na ordem em que ocorrem. Se desabilitado, os eventos podem ser processados em paralelo, o que é mais rápido quando muitos eventos ocorrem ao mesmo tempo. Se a ordenação de eventos estiver habilitada, múltiplas execuções desse trigger ocorrerão sequencialmente com base nos carimbos de data/hora dos eventos de alteração. Se a ordenação de eventos estiver desabilitada, múltiplas execuções desse trigger ocorrerão de forma independente. Dica Otimização de desempenho Desabilite a ordenação de eventos para melhorar o desempenho dos triggers que respondem a operações em massa de banco de dados. Saiba mais.
Skip Events On Re-Enable	Desabilitado por padrão. Se habilitado, quaisquer eventos de alteração ocorridos enquanto esse trigger esteve desabilitado não serão processados.

eventType

Na seção Event Type, você escolhe qual ação será executada quando o trigger for acionado. Você pode optar por executar uma função ou usar o AWS EventBridge.

Avançado

Na seção Advanced, as seguintes opções de configuração opcionais estão disponíveis:

Campo

Descrição

Project Expression

Uma expressão $project que seleciona um subconjunto de campos de cada evento no fluxo de alteração. Você pode usar isso para otimizar a execução do acionador.

A expressão é um objeto que mapeia o nome dos campos no evento de alteração para um 0, que exclui o campo, ou um 1, que o inclui. Uma expressão pode ter valores de 0 ou 1, mas não os dois juntos. Isso divide as projeções em duas categorias – inclusivas e exclusivas:

Uma expressão de projeto inclusiva especifica campos a serem incluídos em cada documento de evento de alteração. A expressão é um objeto que mapeia o nome dos campos para incluir em um 1. Se você não incluir um campo, ele não será incluído no evento de alteração projetado.
Exemplo
A seguinte projeção inclui somente os campos _id e fullDocument:
{ _id: 1, fullDocument: 1 }
Uma expressão de projeto exclusiva especifica os campos a serem excluídos de cada documento de evento de alteração. A expressão é um objeto que mapeia o nome dos campos para incluir em um 0. Se você não excluir um campo, ele será incluído no evento de alteração projetado.
Exemplo
A seguinte projeção exclui os campos _id e fullDocument:
{ _id: 0, fullDocument: 0 }
Observação
Você não pode excluir o campo operation_type com uma projeção. Isso garante que o trigger sempre possa verificar se deve ser executado para o tipo de operação de um determinado evento.

Match Expression

Um documento de expressão $match que o App Services usa para filtrar quais eventos de alteração causam o acionamento do trigger. O trigger avalia todos os objetos de evento de alteração que recebe em relação a essa expressão de correspondência e só é executado se a expressão for avaliada como true para um determinado evento de alteração.

Observação

Usar notação de ponto para campos incorporados

O MongoDB executa uma correspondência de igualdade total para documentos incorporados em uma expressão de correspondência. Se quiser corresponder a um campo específico em um documento incorporado, consulte o campo diretamente usando anotação de ponto. Para obter mais informações, consulte Query sobre documentos incorporados no manual do servidor MongoDB.

Dica

Otimização de desempenho

Limite o número de campos que o trigger processa usando uma expressão $match . Saiba mais.

Maximum Throughput

Se a fonte de dados vinculada for um servidor dedicado (nível M10+), é possível aumentar a taxa de transferência máxima além dos 10.000 processos simultâneos padrão.

Importante

Para habilitar a taxa de transferência máxima, é preciso desabilitar a Ordem de eventos.

Antes de aumentar a taxa de transferência máxima, considere se um ou mais de seus triggers estão chamando uma API externa com taxa limitada. Aumentar a taxa de trigger pode resultar em exceder esses limites.

Aumentar o rendimento também pode adicionar uma carga de trabalho maior, afetando o desempenho geral do cluster.

Alterar tipos de evento

Eventos de alteração de banco de dados representam alterações individuais em uma collection específica do seu cluster MongoDB Atlas vinculado.

Todo evento de banco de dados tem o mesmo tipo de operação e estrutura do objeto de evento de alteração que foi emitido pelo change stream subjacente. Eventos de mudança têm os seguintes tipos de operação:

Tipo de operação	Descrição
Inserir documento (Todos os tipos de trigger)	Representa um novo documento adicionado à collection.
Atualizar documento (Todos os tipos de trigger)	Representa uma alteração a um documento existente na collection.
Excluir documento (todos os tipos de trigger)	Representa um documento excluído da collection.
Substituir documento (Todos os tipos de trigger)	Representa um novo documento que substituiu um documento na collection.
Criar collection (somente tipos de trigger de banco de dados e sistema)	Representa a criação de uma nova collection.
Modificar coleção (somente tipos de gatilho de banco de dados e sistema)	Representa a collection de alteração.
Renomear collection (somente tipos de trigger de banco de dados e sistema)	Representa a collection sendo renomeada.
Descartar collection (somente tipos de trigger de banco de dados e sistema)	Representa uma collection sendo descartada.
Fragmentar collection (somente tipos de trigger de banco de dados e sistema)	Representa uma collection mudando de não fragmentada para fragmentada.
Refragmentar collection (somente tipos de trigger de banco de dados e sistema)	Representa uma alteração na fragmentação de uma collection.
Refinar a chave de shard da collection (somente tipos de trigger de banco de dados e sistema)	Representa uma alteração na chave de fragmento de uma coleção.
Criar índices (somente tipos de trigger de banco de dados e sistema)	Representa a criação de um novo índice.
Descartar índices (somente tipos de trigger de banco de dados e sistema)	Representa um índice sendo descartado.
Descartar banco de dados (somente tipo de trigger de sistema)	Representa um banco de dados sendo descartado.

Objetos de evento de alteração do banco de dados têm o seguinte formato geral:

{
   _id : <ObjectId>,
   "operationType": <string>,
   "fullDocument": <document>,
   "fullDocumentBeforeChange": <document>,
   "ns": {
      "db" : <string>,
      "coll" : <string>
   },
   "documentKey": {
     "_id": <ObjectId>
   },
   "updateDescription": <document>,
   "clusterTime": <Timestamp>
}

Exemplo de gatilho de banco de dados (trigger)

Uma loja online deseja notificar seus clientes sempre que um de seus pedidos muda de local. Eles registram cada pedido na collection store.orders como um documento semelhante a este:

{
  _id: ObjectId("59cf1860a95168b8f685e378"),
  customerId: ObjectId("59cf17e1a95168b8f685e377"),
  orderDate: ISODate("2018-06-26T16:20:42.313Z"),
  shipDate: ISODate("2018-06-27T08:20:23.311Z"),
  orderContents: [
    { qty: 1, name: "Earl Grey Tea Bags - 100ct", price: NumberDecimal("10.99") }
  ],
  shippingLocation: [
    { location: "Memphis", time: ISODate("2018-06-27T18:22:33.243Z") },
  ]
}

Para automatizar esse processo, o armazenamento cria um trigger de banco de dados que escuta eventos de alteração Atualizar na coleção store.orders. Quando o trigger observa um evento de Atualização, ele passa o objeto do evento de alteração para sua função associada, textShippingUpdate. A função verifica o evento de alteração para quaisquer alterações no campo shippingLocation e, se ele tiver sido atualizado, envia uma mensagem de texto para o cliente com a nova localização do pedido.

Configuração do trigger

{
  "type": "DATABASE",
  "name": "shippingLocationUpdater",
  "function_name": "textShippingUpdate",
  "config": {
    "service_name": "mongodb-atlas",
    "database": "store",
    "collection": "orders",
    "operation_types": ["UPDATE"],
    "unordered": false,
    "full_document": true,
    "match": {}
  },
  "disabled": false
}

textShippingUpdate

exports = async function (changeEvent) {
  // Destructure out fields from the change stream event object
  const { updateDescription, fullDocument } = changeEvent;
  // Check if the shippingLocation field was updated
  const updatedFields = Object.keys(updateDescription.updatedFields);
  const isNewLocation = updatedFields.some(field =>
    field.match(/shippingLocation/)
  );
  // If the location changed, text the customer the updated location.
  if (isNewLocation) {
    const { customerId, shippingLocation } = fullDocument;
    const mongodb = context.services.get("mongodb-atlas");
    const customers = mongodb.db("store").collection("customers");
    const { location } = shippingLocation.pop();
    const customer = await customers.findOne({ _id: customerId });
    const twilio = require('twilio')(
      // Your Account SID and Auth Token from the Twilio console:
      context.values.get("TwilioAccountSID"),
      context.values.get("TwilioAuthToken"),
    );
    await twilio.messages.create({
      To: customer.phoneNumber,
      From: context.values.get("ourPhoneNumber"),
      Body: `Your order has moved! The new location is ${location}.`
    })
  }
};

Triggers suspensos

Gatilhos de banco de dados (triggers) podem entrar em um estado suspenso em resposta a um evento que impede que o change stream do trigger continue. Eventos que podem suspender um trigger incluem:

invalidar eventos como dropDatabase, renameCollection ou aqueles causados por uma interrupção na rede.
o token de retomada necessário para retomar o fluxo de alterações não está mais no oplog do cluster. Os logs da aplicação referem-se a isso como um erro ChangeStreamHistoryLost.

No caso de um trigger suspenso ou com falha, o Atlas App Services envia ao proprietário do projeto um e-mail alertando-o sobre o problema.

Retomar automaticamente um trigger suspenso

Você pode configurar um trigger para ser retomado automaticamente se o trigger tiver sido suspenso porque o token de retomada não está mais no oplog. O trigger não processa nenhum evento change stream perdido entre o momento em que o token de retomada é perdido e o momento em que o processo de retomada é concluído.

Ao criar ou atualizar um trigger de banco de dados na UI do App Services, navegue até a página de configuração do trigger que você deseja retomar automaticamente caso seja suspenso.

Na seção Advanced (Optional), selecione Auto-Resume Triggers.

Salve e implante as alterações.

Ao criar ou atualizar um trigger de banco de dados com o Realm CLI, crie ou navegue até o arquivo de configuração do trigger que você deseja retomar automaticamente caso seja suspenso.

No arquivo de configuração do Trigger, inclua o seguinte:

triggers/<trigger name>.json

{
  "name": "<Trigger Name>",
  "type": "DATABASE",
  "config": {
    "tolerate_resume_errors": true,
    // ...rest of Database Trigger configuration
  },
  // ...rest of Trigger general configuration
}

Implemente as alterações com o seguinte comando:

appservices push --remote=<App ID>

Retomar manualmente um trigger suspenso

Quando você retoma manualmente um Gatilho suspenso, seu Aplicativo tenta retomar o Gatilho no próximo evento de fluxo de alteração depois que o fluxo de alterações parou. Se o token de currículo não estiver mais no oplog do cluster, o gatilho deverá ser iniciado sem um token de currículo. Isso significa que o gatilho começa a ouvir novos eventos, mas não processa nenhum evento passado perdido.

Você pode ajustar o tamanho do registro para manter o token de retomada por mais tempo após uma suspensão dimensionando seu cluster do Atlas. Mantenha um tamanho de registro algumas vezes maior do que a taxa de transferência de pico de registro (GB/hora) do cluster para reduzir o risco de um token de retomada de um acionador suspenso descartar o registro antes que o acionador seja executado. Veja a taxa de transferência do oplog de seu cluster no gráfico Oplog GB/Hora nas métricas de cluster do Atlas.

Você pode tentar reiniciar um Trigger suspenso na UI do App Services ou importando um application diretório com a App Services CLI.

Encontrar o trigger suspenso

Na aba Database Triggers da página Triggers, encontre o trigger que você deseja retomar na lista de triggers. O App Services marcam os triggers suspensos com uma Status de Suspended.

Um trigger de banco de dados marcado como suspenso na IU

Reiniciar o gatilho

Clique em Restart na coluna Actions do trigger. Você pode optar por reiniciar o trigger com um token de retomada do fluxo de alterações ou abrir um novo change stream. Indique se deseja ou não usar um token de currículo e clique em Resume Database Trigger.

Observação

Retomar tokens

Se você usar um token de retomada, o App Services tentará retomar o chance stream subjacente do trigger no evento imediatamente após o último evento de alteração processado. Se for bem-sucedido, o trigger processará todos os eventos que ocorreram enquanto ele estava suspenso. Se você não usar um token de retomada, o trigger começará a ouvir novos eventos, mas não disparará para nenhum evento que ocorreu enquanto ele estava suspenso.

O modal de trigger do banco de dados de retomada na interface

Extraia os arquivos de configuração mais recentes do seu aplicativo

appservices pull --remote=<App ID>

Verifique se o arquivo de configuração do trigger existe

Se você exportou uma nova cópia do seu aplicativo, ela já deve incluir um arquivo de configuração atualizado para o trigger suspenso. Você pode confirmar que o arquivo de configuração existe procurando no diretório /triggers um arquivo de configuração de trigger com o mesmo nome do trigger.

Reimplantar o trigger

Depois de verificar se o arquivo de configuração do trigger existe, envie a configuração de volta para seu aplicativo. Os serviços de aplicativos tentam retomar automaticamente todos os gatilhos suspensos incluídos na implantação.

appservices push

Relatório de tempo de gatilho

A lista de triggers na UI do Atlas App Services mostra três carimbos de data/hora:

Última modificação

Esta é a hora em que o trigger foi criado ou alterado mais recentemente.

Último Heartbeat

O Atlas App Services acompanha a última vez que um Trigger foi executado. Se o gatilho não estiver enviando nenhum evento, o servidor enviará uma pulsação para garantir que o token de currículo do gatilho permaneça atualizado. Qualquer evento que seja mais recente é mostrado como Latest Heartbeat.

Hora do Último Cluster Processado

O Atlas App Services também mantém o registro de Last Cluster Time Processed, que é a última vez em que o change stream que apoia um Trigger emitiu um evento. Será mais antigo que Latest Heartbeat se não houver eventos desde a pulsação mais recente.

Otimização de desempenho

Desativar a ordenação de eventos para operações de intermitência

Considere desabilitar a ordenação de eventos se o trigger for acionado em uma collection que recebe rajadas curtas de eventos (por exemplo, inserção de dados como parte de um trabalho em lote diário).

Os Triggers Ordenados esperam para executar uma Função para um evento específico até que as Funções de eventos anteriores tenham terminado de ser executadas. Como consequência, os Triggers Ordenados são efetivamente limitados pelo tempo de execução de cada função do Trigger sequencial. Isso pode causar um atraso significativo entre o evento do banco de dados que aparece no change stream e o acionamento do Trigger. Em alguns casos extremos, os eventos do banco de dados podem cair do oplog antes de um Trigger Ordenado de longa duração processá-los.

Gatilhos não ordenados executam funções em paralelo, se possível, que podem ser consideravelmente mais rápidos (dependendo do seu caso de uso), mas não garante que várias execuções de uma função de gatilho ocorram em ordem de eventos.

Desativar pré-imagens em nível de collection

As pré-imagens de documentos exigem que seu cluster registre dados adicionais sobre cada operação em uma collection. Depois de ativar as pré-imagens para qualquer trigger em uma collection, seu cluster armazena pré-imagens para cada operação na collection.

O espaço de armazenamento adicional e a sobrecarga de computação podem prejudicar o desempenho do acionador , dependendo da configuração do cluster.

Para evitar o armazenamento e a sobrecarga de computação das pré-imagens, você deve desativar as pré-imagens de toda a coleção subjacente do MongoDB. Esta é uma configuração separada de qualquer configuração de pré-imagem de gatilho individual.

Se você desativar as pré-imagens no nível de coleção, nenhum gatilho ativo será ativado essa coleção pode usar pré-imagens. No entanto, se você excluir ou desativar todos os acionadores de pré-imagem em uma coleção, então você também poderá desativar as pré-imagens no nível de coleção.

Para saber como, consulte Desativar Pré-imagens para uma Collection.

Usar Expressões de correspondência para limitar invocações de trigger

Você pode limitar o número de invocações de trigger especificando uma expressão $match no campo Match Expression. O App Services avalia a expressão de correspondência relativamente ao documento de evento de alteração e invoca o trigger apenas se a expressão for avaliada como verdadeira para o evento de alteração determinado.

A expressão match é um JSON document que especifica as condições de query usando a sintaxe de query de leitura do MongoDB.

Recomendamos usar apenas expressões de correspondência quando o volume de eventos de gatilho se tornar mensuravelmente um problema de desempenho. Até lá, receba todos os eventos e manuseie-os individualmente no código de função Trigger.

A forma exata do documento do evento de mudança depende do evento que fez o gatilho disparar. Para obter detalhes, consulte a referência para cada tipo de evento:

Exemplo

A expressão de correspondência a seguir permite que o trigger dispare somente se o objeto de evento de alteração especificar que o campo status em um documento foi alterado.

updateDescription é um campo do objeto Atualizar evento.

{
  "updateDescription.updatedFields.status": {
    "$exists": true
  }
}

A expressão de correspondência a seguir permite que o Trigger seja acionado somente quando o campo needsTriggerResponse de um documento for true. O campo fullDocument dos eventos inserir, atualizar e substituir representa um documento após a operação mostrada. Para receber o campo fullDocument, você deve habilitar Full Document na configuração do Trigger.

{
  "fullDocument.needsTriggerResponse": true
}

Testando Expressões de Correspondência

O procedimento a seguir mostra uma maneira de testar se a expressão correspondente funciona como esperado:

Baixe o MongoDB Shell (mongosh) e use-o para se conectar ao seu cluster.
Substituindo DB_NAME pelo nome do banco de dados, COLLECTION_NAME pelo seu nome da collection e YOUR_MATCH_EXPRESSION pela expressão de correspondência que você deseja testar, cole o seguinte no mongosh para abrir um change stream em uma collection existente:
```
db.getSiblingDB(DB_NAME).COLLECTION_NAME.watch([{$match: YOUR_MATCH_EXPRESSION}])
while (!watchCursor.isClosed()) {
  if (watchCursor.hasNext()) {
    print(tojson(watchCursor.next()));
  }
}
```
Em outra janela do terminal, use o mongosh para fazer alterações em alguns documentos de teste na coleção.
Observe o que o change stream filtra para dentro e para fora.

Usar expressões de projeto para reduzir o tamanho dos dados de entrada

No campo Project Expression, limite o número de campos que o gatilho processa utilizando uma expressão $project.

Observação

O projeto é apenas inclusivo

Ao usar Triggers, uma expressão de projeção é apenas inclusiva. O projeto não suporta a mistura de inclusões e exclusões. A expressão do projeto deve ser inclusiva porque os triggers exigem que você inclua operationType.

Se você quiser excluir um único campo, a expressão de projeção deverá incluir todos os campos, exceto aquele que você deseja excluir. Você só pode excluir explicitamente _id, que está incluído por padrão.

Exemplo

Um gatilho é configurado com os seguintes Project Expression:

{
  "_id": 0,
  "operationType": 1,
  "updateDescription.updatedFields.status": 1
}

O objeto de evento de mudança que os App Services passam para a função de acionamento inclui somente os campos especificados na projeção, conforme no exemplo a seguir:

{
  "operationType": "update",
  "updateDescription": {
    "updatedFields": {
      "status": "InProgress"
    }
  }
}

Exemplos adicionais

Para obter exemplos adicionais de Triggers integrados a um App Services App, confira o exemplo de Triggers no Github.

Voltar

Acionadores

Gatilhos de autenticação