BlogAtlas Vector Search voted most loved vector database in 2024 Retool State of AI reportLearn more >>
MongoDB Developer
Sign in to follow topics
MongoDB Developer Centerchevron-right
Developer Topicschevron-right

Triggers Treats and Tricks: Cascade Document Delete Using Triggers Preimage

Pavel Duchovny3 min read • Published Aug 16, 2021 • Updated May 13, 2022
Facebook Icontwitter iconlinkedin icon
Rate this article
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,
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

MongoDB & Mongoose: Compatibility and Comparison

Apr 02, 2024 | 11 min read

PyMongoArrow: Bridging the Gap Between MongoDB and Your Data Analysis App

Jul 11, 2023 | 7 min read

MongoDB ORMs, ODMs, and Libraries

Apr 02, 2024 | 3 min read

7 Things I Learned While Modeling Data for YouTube Stats

Sep 23, 2022 | 13 min read
Table of Contents
  • Preimage Trigger Option