Getting the previous data in a database trigger

MongoDB Atlas App Services & Realm Atlas Triggers & Functions
#1

Is it possible to get the previous data in a database update trigger event? I have been unable to find anything in the docs that suggests you can.

My scenario is this: I have two collections with a many-to-many relationship: Users and Groups. I’d like to setup a trigger that, when a group has its “members” field updated (an array of ids), it updates each user’s “groups” field to contain that group id.

This is fine for adding members to a group but not removing. If I only receive the current value of the “members” field in the trigger, I’m not able to update the removed users.

#2

Hi, are there any solutions yet for this?

Also, need a way to cancel the action when certain conditions not meet,

For example: cancel update text when length less than 100

#3

It think the question is a bit vague so I don’t know if it’s answerable. What specifically is meant by a

database update trigger event?

Where would you see that in code - within an observe closure or somewhere else?

If the scenario is fine for adding members, why not for removing as that info is also passed within the event?

#4

I am referring to MongoDB Realm Database Triggers.

The issue is when the trigger is called you only receive the updated document, rather than the change diff. I eventually was able to figure out the removed members through a series of collection queries but a change diff would save the need to do that.

#5

The event contains the change differences; any objects that were inserted, modified or removed are in the event data. I am clearly not understanding what you are asking but this

able to figure out the removed members

is exactly what’s contained in the event - it will contain the indices of the removed members.

Collection notifications don’t receive the whole Realm, but instead receive fine-grained descriptions of changes. These consist of the indices of objects that have been added, removed, or modified since the last notification.

#6

Hm, well, I was not able to find that info in the change event. Both the updateDescription and fullDocument contained the same values for the document and I didn’t see anywhere that contained the previous value or a change diff, so I suppose I must have missed it.

Either way, I have since moved on from mongodb to another service, so unfortunately I won’t be able to take another look and see what I was missing. I will mark this as resolved.

#7

Hello,

what we need is the old data right before it is updated, the updateDescriptions, and other params given in the trigger only contains the updated data, not the data before it is updated.

ultimately in the end, what I want to achieve is a logic to reject a document update if certain conditions are not met, and to process that logic I need to compare the new data with its old version right before it is updated.

this might be OOT, is there any way to achieve this?

#8

I understand the question and just a couple of general thoughts. There are two issues as work.

The first being that Realm notification events fire after the write has been committed so there is no ‘prior data’ available at that point.

The second is the timing. If this is the objective

ultimately in the end, what I want to achieve is a logic to reject a document update if certain conditions are not met

rejecting it within that notification is the wrong place to do it - if you want to deny a change or delete, it should be done way before that time.

Much of this occurs asynchronously so you don’t want to be caught in a race condition when determining if data should be altered.

Imagine a multi-user To Do list where one of the To Do’s is ‘locked’ so other users don’t delete it. When another user attempts the delete, you don’t want to wait for a notification or event to occur, the code should check to see if the locked property is set, and when the result of that test asynchronously returns, either approve or deny the request.

That being said, if you really want to do handle it in a notification fashion, you could craft some type of soft delete. For example, add a property ‘status’ and when a user want to delete something set it to ‘delete’ The observer will catch that in an event, see the status is set to ‘delete’ perform your check and if it passes, then perform the actual delete, ensuring you don’t fire another event.

#9

This topic was automatically closed 5 days after the last reply. New replies are no longer allowed.