Triggers Treats and Tricks: Cascade Document Delete Using Triggers Preimage
Rate this article
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.
- 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,
gamescollection holding data for a specific game including ids referencing a
questscollection holding a per game quest. As amount of quest data per game can be large and complex, we’d rather not embed it in
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.
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.
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).
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,
To enable the “Preimage” feature, we will toggle Document Preimage to “ON” and specify our function to handle the cascade delete logic.
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.
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.”
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.