데이터베이스 트리거
이 페이지의 내용
데이터베이스 트리거를 사용하면 연결된 MongoDB Atlas 클러스터에서 데이터베이스 변경이 발생할 때마다 서버 측 로직을 실행할 수 있습니다. 컬렉션, 전체 데이터베이스, 전체 클러스터에서 트리거를 구성할 수 있습니다.
데이터베이스 서버에서 실행되는 SQL 데이터 트리거와 달리 트리거는 데이터베이스 서버와 관계없이 독립적으로 확장되는 서버리스 컴퓨팅 계층에서 실행됩니다. 트리거는 자동으로 Atlas Function을 호출하고 AWS EventBridge를 통해 외부 핸들러에 이벤트를 전달할 수 있습니다.
데이터베이스 트리거를 사용해 이벤트 기반 데이터 상호 작용을 구현합니다. 예를 들어, 관련 문서가 변경될 때 한 문서의 정보를 자동으로 업데이트하거나 새 문서가 삽입될 때마다 외부 서비스에 요청을 보낼 수 있습니다.
데이터베이스 트리거는 MongoDB 변경 스트림을 사용하여 컬렉션의 실시간 변경 사항을 감시합니다. 변경 스트림은 일련의 데이터베이스 이벤트를 말하는데, 각각의 이벤트에는 컬렉션 내 문서에 대한 연산이 설명되어 있습니다. 앱은 컬렉션에서 생성된 각 데이터베이스 트리거에 대해 새 변경 스트림을 엽니다.
중요
변경 스트림 제한
cluster에서 열 수 있는 총 변경 스트림 수에는 cluster 크기에 따라 제한이 있습니다. 자세한 내용은 변경 스트림 제한 사항을 참조하세요.
서버리스 인스턴스 또는 연합 데이터베이스 인스턴스에서는 변경 스트림을 지원하지 않으므로 데이터베이스 트리거를 정의할 수 없습니다.
트리거가 실행되도록 하는 작업과 트리거가 실행되면 어떤 일이 발생하는지 제어할 수 있습니다. 예를 들어 문서의 특정 필드가 업데이트될 때마다 함수를 실행할 수 있습니다. 이 함수는 전체 변경 이벤트에 액세스할 수 있으므로 항상 변경된 내용을 파악할 수 있습니다. 또한 변경 이벤트를 AWS EventBridge로 전달하여 Atlas 외부에서 이벤트를 처리할 수도 있습니다.
트리거는 변경 이벤트를 필터링하는 $match 표현식과 각 이벤트에 포함되는 데이터를 제한하는 $project 표현식을 지원합니다.
경고
배포 및 데이터베이스 수준 트리거에서는 다른 트리거가 실행되어 재귀가 발생하는 방식으로 트리거를 구성할 수 있습니다. 예시로는 동일한 데이터베이스 내의 컬렉션에 기록하는 데이터베이스 수준 트리거 또는 동일한 클러스터의 다른 데이터베이스에 로그를 기록하는 클러스터 수준 로거 또는 로그 전달자가 포함됩니다.
데이터베이스 트리거 생성
App Services UI에서 데이터베이스 트리거 구성 화면을 열려면 왼쪽 탐색 메뉴에서 Triggers 을 클릭하고 Create a Trigger를 클릭한 다음 Trigger Type 옆에 있는 Database 탭을 선택합니다.
트리거를 구성한 다음 페이지 하단의 Save을 클릭하여 현재 배포 초안에 추가하세요.
App Services CLI를 사용하여 데이터베이스 트리거를 만들려면 다음을 수행하세요.
참고
Atlas App Services는 Trigger 구성 파일에 대해 특정 파일 이름을 강제하지 않습니다. 그러나 가져오기 후 Atlas App Services는 정의한 Trigger 이름과 일치하도록 각 구성 파일의 이름을 바꿉니다. 예: mytrigger.json.
구성
데이터베이스 트리거에는 다음과 같은 구성 옵션이 있습니다.
Trigger 세부 정보
Trigger Details 섹션에서 먼저 Trigger Type을 선택합니다. 데이터베이스 트리거의 경우 이 값을 Database로 설정합니다.
다음으로, 원하는 세분화 수준에 따라 Watch Against을 선택합니다. 옵션은 다음과 같습니다.
Collection지정된 컬렉션에 변경 사항이 발생하는 경우
Database지정된 데이터베이스의 어떤 컬렉션에서든 변화가
Deployment지정된 cluster에서 배포 변경이 발생하는 경우. 배포 소스 유형을 선택하면 다음 데이터베이스에서 변경 내용이 감시되지 않습니다 .
관리 데이터베이스
admin,local,config동기화 데이터베이스
__realm_sync와__realm_sync_<app_id>
중요
배포 수준 소스 유형은 전용 계층에서만 사용할 수 있습니다.
사용 중인 소스 유형에 따라 추가 옵션이 달라집니다. 다음 표에서 옵션에 대한 설명을 살펴보세요.
소스 유형 | 옵션 |
|---|---|
Collection |
|
Database |
|
Deployment |
|
팁
사전 이미지 및 성능 최적화
사전 이미지에는 추가 스토리지 오버헤드가 필요하며 이는 성능에 영향을 줄 수 있습니다. 컬렉션에서 사전 이미지를 사용하지 않는 경우 사전 이미지를 비활성화해야 합니다. 자세한 내용은 컬렉션 수준 사전 이미지 비활성화를 참조하세요.
문서 사전 이미지는 MongoDB 4.4 이상을 실행하는 비샤드형 Atlas 클러스터와 MongoDB 5.3 이상을 실행하는 샤드형 Atlas 클러스터에서 지원됩니다. 클러스터가 5.3 이상을 실행하는 한 비샤딩된 클러스터(사전 이미지 포함)를 샤딩된 클러스터로 업그레이드할 수 있습니다.
트리거 구성
필드 | 설명 |
|---|---|
Auto-Resume Triggers | 활성화되어 있고, 클러스터의 oplog에서 이 트리거의 재개 토큰을 찾을 수 없는 경우, 트리거는 다음번 관련 변경 스트림 이벤트에서 자동으로 이벤트 처리를 재개합니다. 트리거가 일시 중단된 시점부터 트리거가 실행을 재개할 때까지의 모든 변경 스트림 이벤트에는 트리거가 실행되지 않습니다. |
Event Ordering | 활성화하면 트리거 이벤트가 발생한 순서대로 처리됩니다. 비활성화하면 이벤트를 병렬로 처리할 수 있으므로 동시에 많은 이벤트가 발생할 때 속도가 더 빨라집니다. 이벤트 순서 지정이 활성화되면 변경 이벤트의 타임스탬프를 기준으로 이 트리거가 순차적으로 여러 번 실행됩니다. 이벤트 순서 지정이 비활성화되면 이 트리거가 순서에 관계없이 여러 번 실행됩니다. |
Skip Events On Re-Enable | 기본적으로 비활성화되어 있습니다. 활성화하면 이 트리거가 비활성화된 동안 발생한 모든 변경 이벤트가 처리되지 않습니다. |
eventType
Event Type 섹션에서 트리거가 실행될 때 수행할 작업을 선택합니다. 함수를 실행하거나 AWS EventBridge를 사용하도록 선택할 수 있습니다.
고급
Advanced 섹션에서 다음과 같은 선택적 구성 옵션을 사용할 수 있습니다.
필드 | 설명 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
Project Expression | 변경 스트림의 각 이벤트에서 필드의 하위 집합을 선택하는 $project 표현식입니다. 이 표현식을 사용해 트리거의 실행을 최적화할 수 있습니다. 표현식은 변경 이벤트의 필드 이름을 필드를 제외한
| ||||||||
Match Expression | App Services가 트리거를 발생시키는 변경 이벤트를 필터링하는 데 사용하는 $match 표현식 문서입니다. 트리거는 이 일치 표현식에 대해 수신한 모든 변경 이벤트 객체를 평가하며 해당 변경 이벤트에 대해 표현식이 참고내장된 필드에 점 표기법 사용MongoDB는 일치 표현식에 내장된 문서에 대해 완전한 동등성 매치를 수행합니다. 내장된 문서에서 특정 필드를 일치시키려면 점 표기법을 사용해 해당 필드를 직접 참조해야 합니다. 자세한 내용은 MongoDB 서버 매뉴얼의 내장된 문서에 대한 쿼리를 참조하세요. | ||||||||
Maximum Throughput | 연결된 데이터 소스가 전용 서버(M10+ 계층)인 경우 최대 처리량을 기본 동시 프로세스 10,000개 이상으로 늘릴 수 있습니다. 중요처리량을 최대화하려면 이벤트 순서를 비활성화해야 합니다. 최대 처리량을 늘리기 전에 하나 이상의 트리거가 속도 제한이 있는 외부 API를 호출하고 있는지 고려하세요. 트리거 속도를 높이면 이러한 제한을 초과할 수 있습니다. 처리량을 늘리면 워크로드도 더 커져 전체 클러스터 성능에 영향을 줄 수 있습니다. |
변경 이벤트 유형
데이터베이스 변경 이벤트는 연결된 MongoDB Atlas 클러스터의 특정 컬렉션에 대한 개별 변경 사항을 나타냅니다.
모든 데이터베이스 이벤트는 기본 변경 스트림에 의해 방출된 변경 스트림 객체와 동일한 작업 유형 및 구조를 갖습니다. 변경 이벤트에는 다음과 같은 작업 유형이 있습니다.
작업 유형 | 설명 |
|---|---|
문서 삽입(모든 트리거 유형) | 컬렉션에 추가된 새 문서를 나타냅니다. |
문서 업데이트(모든 트리거 유형) | 컬렉션의 기존 문서에 대한 변경 사항을 나타냅니다. |
문서 삭제(모든 트리거 유형) | 컬렉션에서 삭제된 문서를 나타냅니다. |
문서 대체(모든 트리거 유형) | 컬렉션의 문서를 대체한 새 문서를 나타냅니다. |
컬렉션 생성(데이터베이스 및 배포 트리거 유형에만 해당) | 새 컬렉션 생성을 나타냅니다. |
컬렉션 수정(데이터베이스 및 배포 트리거 유형에만 해당) | 수정 컬렉션을 나타냅니다. |
컬렉션 이름 변경(데이터베이스 및 배포 트리거 유형에만 해당) | 컬렉션 이름이 변경되는 것을 나타냅니다. |
컬렉션 제거(데이터베이스 및 배포 트리거 유형에만 해당) | 제거되는 컬렉션을 나타냅니다. |
컬렉션 샤드(데이터베이스 및 배포 트리거 유형에만 해당) | 컬렉션이 비샤드형에서 샤드형으로 변경되는 것을 나타냅니다. |
컬렉션 재샤드(데이터베이스 및 배포 트리거 유형에만 해당) | 컬렉션의 샤딩에 대한 변경을 나타냅니다. |
컬렉션 샤드 키 구체화(데이터베이스 및 배포 트리거 유형에만 해당) | 컬렉션의 샤드 키 변경을 나타냅니다. |
인덱스 생성 (데이터베이스 및 배포 트리거 유형에만 해당) | 새 인덱스 생성을 나타냅니다. |
인덱스 제거(데이터베이스 및 배포 트리거 유형에만 해당) | 제거되는 인덱스를 나타냅니다. |
데이터베이스 제거(배포 트리거 유형에만 해당) | 제거되는 데이터베이스를 나타냅니다. |
데이터베이스 변경 이벤트 객체의 일반적인 형태는 다음과 같습니다.
{ _id : <ObjectId>, "operationType": <string>, "fullDocument": <document>, "fullDocumentBeforeChange": <document>, "ns": { "db" : <string>, "coll" : <string> }, "documentKey": { "_id": <ObjectId> }, "updateDescription": <document>, "clusterTime": <Timestamp> }
데이터베이스 트리거 예시
온라인 스토어에서 고객이 주문하는 위치가 변경될 때마다 이를 고객에게 알리려고 합니다. 이 스토어는 각 주문을 store.orders 컬렉션에 다음과 같은 문서로 기록합니다.
{ _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") }, ] }
스토어는 이 프로세스를 자동화하기 위해 store.orders 컬렉션에서 업데이트 변경 이벤트를 수신하는 데이터베이스 트리거를 생성합니다. 트리거는 업데이트 이벤트를 관찰하면 변경 이벤트 객체를 연관된 함수 textShippingUpdate 에 전달합니다. 함수는 shippingLocation 필드에 대한 변경 사항이 있는지 변경 이벤트를 확인하고, 업데이트된 경우 주문의 새 위치가 포함된 문자 메시지를 고객에게 보냅니다.
{ "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 }
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}.` }) } };
일시 중단된 트리거
데이터베이스 트리거는 트리거의 변경 스트림이 계속되지 못하게 하는 이벤트에 대한 응답으로 일시 중단 상태가 될 수 있습니다. 트리거를 일시 중지할 수 있는 이벤트는 다음과 같습니다.
dropDatabase,renameCollection또는 네트워크 장애로 인한 이벤트를 무효화합니다.변경 스트림을 재개하는 데 필요한 재개 토큰이 더 이상 클러스터 oplog에 없습니다. 앱 로그는 이를
ChangeStreamHistoryLost오류로 표시합니다.
트리거하다 일시 중단되거나 실패하는 경우, Atlas App Services에서 프로젝트 소유자에게 문제를 알리는 이메일을 보냅니다.
일시 중단된 트리거 자동으로 재개
다시 시작 토큰이 oplog에 더 이상 있지 않아서 Atlas Triggers가 일시 중단된 경우 자동으로 다시 시작하도록 트리거를 구성할 수 있습니다. 트리거는 다시 시작 토큰이 손실된 시점과 다시 시작 프로세스가 완료된 시점 사이에 누락된 변경 스트림 이벤트를 처리하지 않습니다.
App Services UI에서 데이터베이스 트리거를 생성 또는 업데이트하다가 일시 중단된 경우 자동으로 다시 시작하려는 트리거의 구성 페이지로 이동합니다.
Advanced (Optional) 섹션에서 Auto-Resume Triggers를 선택합니다.
변경 사항을 저장하고 배포합니다.
Realm CLI를 사용하여 데이터베이스 트리거를 생성 또는 업데이트할 때 일시 중단된 경우 자동으로 다시 시작하려는 트리거의 구성 파일을 만들거나 이동합니다.
Trigger의 구성 파일에 다음을 포함하세요.
{ "name": "<Trigger Name>", "type": "DATABASE", "config": { "tolerate_resume_errors": true, // ...rest of Database Trigger configuration }, // ...rest of Trigger general configuration }
다음 명령을 사용하여 변경 사항을 배포합니다.
appservices push --remote=<App ID>
일시 중단된 트리거 수동으로 재개
일시 중단된 트리거를 수동으로 다시 시작하면 앱은 변경 스트림이 중지된 후 다음 변경 스트림 이벤트에서 트리거를 다시 시작하려고 시도합니다. 재개 토큰이 더 이상 cluster oplog에 없는 경우 재개 토큰 없이 트리거를 시작해야 합니다. 이는 트리거가 새 이벤트 수신을 시작하지만 누락된 과거 이벤트를 프로세스하지 않음을 의미합니다.
Atlas 클러스터를 확장하여 일시 중단 후 더 많은 시간 동안 재개 토큰을 유지하도록 oplog 크기를 조정할 수 있습니다. oplog 크기를 클러스터의 최대 oplog 처리량(GB/시간)보다 몇 배 더 크게 유지하여 트리거가 실행되기 전에 일시 중단된 트리거의 재개 토큰이 oplog를 제거하는 위험을 줄입니다. Atlas 클러스터 지표의 Oplog GB/시간 그래프에서 클러스터의 oplog 처리량을 확인합니다.
App Services UI에서 또는 App Services CLI를 통해 애플리케이션 디렉토리를 가져와 일시 중단된 트리거를 재시작할 수 있습니다.
트리거 다시 시작
trigger의 Actions 열에서 Restart을 클릭합니다. 변경 스트림 재개 토큰을 사용하여 trigger를 다시 시작하거나 새 변경 스트림을 열도록 선택할 수 있습니다. 재개 토큰을 사용할지 여부를 지정한 후 Resume Database Trigger를 클릭하세요.
참고
토큰 재개
재개 토큰을 사용하는 경우 App Services는 처리한 마지막 변경 이벤트 직후의 이벤트에서 trigger의 기본 변경 스트림을 재개하려고 시도합니다. 성공 시 trigger는 일시 중단된 동안 발생한 모든 이벤트를 처리합니다. 재개 토큰을 사용하지 않는 경우에는 trigger가 새 이벤트 수신을 시작하지만 일시 중단된 동안 발생한 이벤트에 대해서는 실행되지 않습니다.
trigger 구성 파일이 존재하는지 확인
애플리케이션의 새 복사본을 내보낸 경우 일시 중단된 트리거에 대한 최신 구성 파일이 이미 포함되어 있어야 합니다. /triggers 디렉토리에서 트리거와 이름이 같은 트리거 구성 파일을 찾아 구성 파일이 존재하는지 확인할 수 있습니다.
트리거 시간 보고
Atlas App Services UI의 트리거 목록에서는 3개의 타임스탬프를 볼 수 있습니다.
마지막으로 수정한 날짜
트리거가 생성되었거나 가장 최근에 변경된 시간입니다.
최근 심장 박동
Atlas App Services는 가장 최근에 트리거가 실행된 시간을 추적합니다. 트리거가 어떤 이벤트도 전송하지 않는 경우, 서버는 하트비트를 보내 트리거의 재개 토큰이 최신 상태로 유지되도록 보장합니다. 가장 최근의 이벤트는 Latest Heartbeat로 표시됩니다.
마지막 클러스터 처리 시간
또한 Atlas App Services는 Trigger를 뒷받침하는 변경 스트림이 마지막으로 이벤트를 내보낸 시간인 Last Cluster Time Processed를 추적합니다. 가장 최근 하트비트 이후 이벤트가 없으면 Latest Heartbeat보다 오래된 것입니다.
성능 최적화
버스트 작업에 대한 이벤트 순서 지정 비활성화
짧은 이벤트 버스트를 수신하는 컬렉션션에서 트리거가 실행되는 경우 이벤트 순서 지정을 비활성화하는 것이 좋습니다(예: 일일 배치 작업의 일부로 데이터 삽입).
순서가 지정된 트리거는 이전 이벤트의 함수 실행이 완료될 때까지 특정 이벤트에 대한 함수가 실행될 때까지 기다립니다. 따라서 순서가 지정된 트리거는 각 순차 트리거 함수의 실행 시간에 따라 속도가 효과적으로 제한됩니다. 이로 인해 변경 스트림에 나타나는 데이터베이스 이벤트와 트리거 실행 사이에 상당한 지연이 발생할 수 있습니다. 극단적인 경우에는 장기 실행되는 순서가 지정된 트리거가 데이터베이스 이벤트를 처리하기 전에 oplog에서 데이터베이스 이벤트가 삭제될 수 있습니다.
순서가 지정되지 않은 트리거는 가능한 경우 함수를 병렬로 실행하므로 사용 사례에 따라 훨씬 빠를 수 있지만 트리거 함수의 여러 실행이 이벤트 순서대로 발생한다는 보장은 없습니다.
컬렉션 수준 사전 이미지 비활성화하기
문서 사전 이미지를 사용하려면 클러스터가 컬렉션의 각 작업에 대한 추가 데이터를 기록해야 합니다. 컬렉션의 트리거에 대해 사전 이미지를 활성화하면 클러스터는 컬렉션의 모든 작업에 대한 사전 이미지를 저장합니다.
추가 스토리지 공간과 컴퓨팅 오버헤드는 클러스터 구성에 따라 트리거 성능이 저하될 수 있습니다.
사전 이미지의 저장 및 계산 오버헤드를 방지하려면 전체 기본 MongoDB 컬렉션에 대해 사전 이미지를 비활성화해야 합니다. 이는 개별 트리거의 사전 이미지 설정과는 별개의 설정입니다.
컬렉션 수준 사전 이미지를 비활성화하면 해당 컬렉션의 활성 트리거가 사전 이미지를 사용할 수 없습니다. 그러나 컬렉션의 모든 사전 이미지 트리거를 삭제하거나 비활성화하는 경우 컬렉션 수준 사전 이미지도 비활성화할 수 있습니다.
방법을 알아보려면 컬렉션에 대한 미리보기 이미지 비활성화를 참조하세요.
일치 표현식을 사용하여 트리거 호출 제한하기
Match Expression 필드에 $match 표현식을 지정하여 트리거 호출 횟수를 제한할 수 있습니다. App Services는 변경 이벤트 문서를 기준으로 일치 표현식을 평가하고, 지정된 변경 이벤트와 관련해 표현식이 true로 평가되는 경우에만 트리거를 호출합니다.
일치 표현식은 MongoDB 읽기 쿼리 구문을 사용해 쿼리 조건을 지정하는 JSON document입니다.
Trigger 이벤트의 양이 측정 가능한 수준으로 성능 문제가 되는 경우에만 일치 표현식을 사용하는 것이 좋습니다. 그때까지 모든 이벤트를 수신하고 Trigger 함수 코드에서 개별적으로 처리합니다.
변경 이벤트 문서의 정확한 형태는 트리거가 실행되도록 야기한 이벤트에 따라 달라집니다. 자세한 내용은 이벤트 유형별 참고 자료를 참조하세요.
예시
다음 일치 표현식을 사용하면 변경 이벤트 객체가 문서의 status 필드가 변경되었음을 지정하는 경우에만 트리거가 실행될 수 있습니다.
updateDescription 이벤트 객체 업데이트의 필드입니다.
{ "updateDescription.updatedFields.status": { "$exists": true } }
다음 일치 표현식을 사용하면 문서의 needsTriggerResponse 필드가 true인 경우에만 트리거가 실행되도록 할 수 있습니다. 삽입, 업데이트 및 바꾸기 이벤트의 fullDocument 필드는 지정된 작업 후의 문서를 나타냅니다. fullDocument 필드를 수신하려면 트리거 구성에서 Full Document를 활성화해야 합니다.
{ "fullDocument.needsTriggerResponse": true }
일치 표현식 테스트
다음 절차에서는 일치 표현식이 예상대로 작동하는지 테스트하는 한 가지 방법을 보여줍니다.
MongoDB Shell(mongosh)을 다운로드하고 클러스터에 연결합니다.
DB_NAME을 데이터베이스 이름으로,COLLECTION_NAME을 컬렉션 이름으로,YOUR_MATCH_EXPRESSION을 테스트하려는 일치 표현식으로 대체하고 다음을 mongosh에 붙여 넣어 기존 컬렉션에서 변경 스트림을 엽니다.db.getSiblingDB(DB_NAME).COLLECTION_NAME.watch([{$match: YOUR_MATCH_EXPRESSION}]) while (!watchCursor.isClosed()) { if (watchCursor.hasNext()) { print(tojson(watchCursor.next())); } } 다른 터미널 창에서 mongosh를 사용하여 컬렉션의 일부 테스트 문서를 변경합니다.
변경 스트림이 필터링을 통해 무엇을 남기고 무엇을 걸러 내는지 관찰합니다.
프로젝트 표현식을 사용하여 입력 데이터 크기 줄이기
Project Expression 필드에서 $project 표현식을 사용하여 트리거가 처리하는 필드 수를 제한합니다.
참고
프로젝트만 포함
트리거를 사용할 때는 프로젝션 표현식만 포함됩니다. 프로젝트는 포함과 제외의 혼합을 지원하지 않습니다. 트리거에는 operationType을 포함해야 하므로 프로젝트 표현식은 포괄적이어야 합니다.
단일 필드를 제외하려면 프로젝션 표현식에 제외할 필드를 제외한 모든 필드가 포함되어야 합니다. 기본적으로 포함된 _id만 명시적으로 제외할 수 있습니다.
예시
트리거는 다음 Project Expression으로 구성됩니다.
{ "_id": 0, "operationType": 1, "updateDescription.updatedFields.status": 1 }
App Services가 트리거 함수에 전달하는 변경 이벤트 객체에는 다음 예제와 같이 프로젝션에 지정된 필드만 포함됩니다.
{ "operationType": "update", "updateDescription": { "updatedFields": { "status": "InProgress" } } }
추가 예시
App Services 앱에 통합된 트리거의 추가 예를 보려면 Github의 트리거 예제를 확인하세요.