EventGet 50% off your ticket to MongoDB.local NYC on May 2. Use code Web50!Learn more >>
MongoDB Developer
MongoDB
plus
Sign in to follow topics
MongoDB Developer Centerchevron-right
Developer Topicschevron-right
Productschevron-right
MongoDBchevron-right

Triggers Treats and Tricks: Cascade Document Delete Using Triggers Preimage

Pavel Duchovny3 min read • Published Aug 16, 2021 • Updated May 13, 2022
MongoDB
Facebook Icontwitter iconlinkedin icon
Rate this article
star-empty
star-empty
star-empty
star-empty
star-empty
In this blog series, we are trying to inspire you with some reactive Realm trigger use cases. We hope these will help you bring your application pipelines to the next level.
Essentially, triggers are components in our Atlas projects/Realm apps that allow a user to define a custom function to be invoked on a specific event.
  • Database triggers: We have triggers that can be triggered based on database events—like deletes, inserts, updates, and replaces—called database triggers.
  • Scheduled triggers: We can schedule a trigger based on a cron expression via scheduled triggers.
  • Authentication triggers: These triggers are only relevant for Realm authentication. They are triggered by one of the Realm auth providers' authentication events and can be configured only via a Realm application.
Relationships are an important part of any data design. Relational databases use primary and foreign key concepts to form those relationships when normalizing the data schema. Using those concepts, it allows a “cascading'' delete, which means a primary key parent delete will delete the related siblings.
MongoDB allows you to form relationships in different ways—for example, by embedding documents or arrays inside a parent document. This allows the document to contain all of its relationships within itself and therefore it does the cascading delete out of the box. Consider the following example between a user and the assigned tasks of the user:
Delete of this document will delete all the tasks.
However, in some design cases, we will want to separate the data of the relationship into Parent and Sibling collections—for example, games collection holding data for a specific game including ids referencing a quests collection holding a per game quest. As amount of quest data per game can be large and complex, we’d rather not embed it in games but reference:
Games collection
Each game has a quest array with a start time of this quest and a reference to the quests collection where the quest data reside.
Quests collection
When a game gets deleted, we would like to purge the relevant quests in a cascading delete. This is where the Preimage trigger feature comes into play.

Preimage Trigger Option

The Preimage option allows the trigger function to receive a snapshot of the deleted/modified document just before the change that triggered the function. This feature is enabled by enriching the oplog of the underlying replica set to store this snapshot as part of the change. Read more on our documentation.
In our case, we will use this feature to capture the parent deleted document full snapshot (games) and delete the related relationship documents in the sibling collection (quests).

Building the Trigger

When we define the database trigger, we will point it to the relevant cluster and parent namespace to monitor and trigger when a document is deleted—in our case, GamesDB.games.
Trigger  Def
To enable the “Preimage” feature, we will toggle Document Preimage to “ON” and specify our function to handle the cascade delete logic.
Preimage Toggle
deleteCascadingQuests - Function
As you can see, the function gets the fully deleted “games” document present in “changeEvent.fullDocumentBeforeChange” and iterates over the “quests” array. For each of those array elements, the function runs a “deleteOne” on the “quests” collection to delete the relevant quests documents.

Deleting the Parent Document

Now let's put our trigger to the test by deleting the game from the “games” collection:
Once the document was deleted, our trigger was fired and now the “quests” collection is empty as it had only quests related to this deleted game: Our cascade delete works thanks to triggers “Preimages.”

Wrap Up

The ability to get a modified or deleted full document opens a new world of opportunities for trigger use cases and abilities. We showed here one option to use this new feature but this can be used for many other scenarios, like tracking complex document state changes for auditing or cleanup images storage using the deleted metadata documents.
We suggest that you try this new feature considering your use case and look forward to the next trick along this blog series.
Want to keep going? Join the conversation over at our community forums!

Facebook Icontwitter iconlinkedin icon
Rate this article
star-empty
star-empty
star-empty
star-empty
star-empty
Related
Code Example

Magazine Management


Jul 07, 2022 | 0 min read
Code Example

How to Use MongoDB Client-Side Field Level Encryption (CSFLE) with C#


Sep 23, 2022 | 18 min read
Article

Structuring Data with Serde in Rust


May 12, 2022 | 5 min read
Article

Case-Insensitive Queries Without Case-Insensitive Indexes


May 31, 2022 | 8 min read
Table of Contents