Differentiate trigger events

MongoDB Atlas
1

I have a simple array in my collection and I call one of 2 update events against it:

$addToSet: { myArray: 'String' }

OR

$pull: { myArray: 'String' }

I need to have a trigger run on both events.

So my questions are:

  1. Is there anyway to know if a $addToSet OR $pull command was run?

  2. How can I get the String that was added or removed by the $addToSet OR $pull command?

Thanks

3

Hi @Dev_Ops,

I have a simple array in my collection and I call one of 2 update events against it

I presume the $addToSet and $pull operators are used in either a db.collection.update(), db.collection.updateOne() or db.collection.updateMany() operation but please correct me if I am wrong here.

  1. Is there anyway to know if a $addToSet OR $pull command was run?
  2. How can I get the String that was added or removed by the $addToSet OR $pull command?

Depending on your use case and requirements, you may wish to Set Up Database Auditing although please note that this feature is not available for M0 free clusters, M2 , and M5 clusters. There are a few lines from a mongodb-audit-log file from my test environment for your reference to see if it contains details you are after:

Please see the two below example log entries for the following operations in my test environment:

/// For db.testcollection.updateOne({a:1},{$addToSet:{colours:"red"}})
{ "atype" : "authCheck", "ts" : { "$date" : "2022-05-18T04:11:31.515+00:00" },..."param" : { "command" : "update", "ns" : "myFirstDatabase.testcollection", "args" : { "update" : "testcollection", "updates" : [ { "q" : { "a" : 1 }, "u" : { "$addToSet" : { "colours" : "red" } } } ],...

/// For db.testcollection.updateOne({a:1},{$pull:{colours:"red"}})
{ "atype" : "authCheck", "ts" : { "$date" : "2022-05-18T04:11:47.555+00:00" },..."param" : { "command" : "update", "ns" : "myFirstDatabase.testcollection", "args" : { "update" : "testcollection", "updates" : [ { "q" : { "a" : 1 }, "u" : { "$pull" : { "colours" : "red" } } } ],...

You can see from the above examples the value for the "colours" field (which is of type array) when using both the $addToSet and $pull operator (in this case the value "red") are recorded.

Please note that i’ve redacted some of the information from the log lines. Additionally, Turning on this feature will increase your daily cluster pricing. Read more.

If this sounds like this may help, you may find the procedure on how to enable Database Auditing documentation useful.

Another possible other method that may work for you depending on your use case is to log the operations and variable values at the application level. Of course this won’t depend on your Atlas cluster tier.

Lastly, if you’re wishing to compare the before and after documents then the following SERVER-36941 ticket may be relevant to you which is pending release in MongoDB 6.0.

Hope this helps. If you require further assistance please let us know more details about your environment, use case and requirements.

Regards,
Jason

1 Like
4

Thanks for your response @Jason_Tran

The updates will be taking place via a db.colloctions.update() event as you assumed.

How would I be able to access the audit-log-file in a Trigger that is configured to use AWS EventBridge?

This trigger is simply to notify a user of a change to their account based on a $addToSet or $pull event taking place against a specific array in their profile.

I really need to know if what I am trying to do is even possible from a MongoDB Atlas standpoint, that way I can look at other options of notifying the user.

Thank you

6

How would I be able to access the audit-log-file in a Trigger that is configured to use AWS EventBridge?

After reading your most recent comment, the mongodb-audit-log file contents may not be necessary as it seems you are after a more immediate notification style alert rather than viewing / auditing the information in a log. Please correct me if I am wrong here. In any case, the trigger won’t be able to access the contents of the log file.

I really need to know if what I am trying to do is even possible from a MongoDB Atlas standpoint, that way I can look at other options of notifying the user.

Via triggers, you won’t be able to see the $addToSet or $pull operation in detail like what was shown in the log examples in my previous comment:

mongodb-audit-log example lines:
/// For db.testcollection.updateOne({a:1},{$addToSet:{colours:"red"}})
{ "atype" : "authCheck", "ts" : { "$date" : "2022-05-18T04:11:31.515+00:00" },..."param" : { "command" : "update", "ns" : "myFirstDatabase.testcollection", "args" : { "update" : "testcollection", "updates" : [ { "q" : { "a" : 1 }, "u" : { "$addToSet" : { "colours" : "red" } } } ],...

/// For db.testcollection.updateOne({a:1},{$pull:{colours:"red"}})
{ "atype" : "authCheck", "ts" : { "$date" : "2022-05-18T04:11:47.555+00:00" },..."param" : { "command" : "update", "ns" : "myFirstDatabase.testcollection", "args" : { "update" : "testcollection", "updates" : [ { "q" : { "a" : 1 }, "u" : { "$pull" : { "colours" : "red" } } } ],...

In saying so, perhaps usage of the triggers containing the contents of the fullDocument and fullDocumentBeforeChange. The following examples are log lines from an test trigger function:

/// Performed `db.arraycoll.update({j:1},{$addToSet:{colours:"grey"}})`
Logs:
[
  "full document BEFORE change = {\"_id\":\"6285a86fbf866c9d2ca4b991\",\"j\":1,\"colours\":[\"blue\",\"green\"]}",
  "full document AFTER change ={\"_id\":\"6285a86fbf866c9d2ca4b991\",\"j\":1,\"colours\":[\"blue\",\"green\",\"grey\"]}"
]

/// Performed `db.arraycoll.update({j:1},{$pull:{colours:"grey"}})`
Logs:
[
  "full document BEFORE change = {\"_id\":\"6285a86fbf866c9d2ca4b991\",\"j\":1,\"colours\":[\"blue\",\"green\",\"grey\"]}",
  "full document AFTER change ={\"_id\":\"6285a86fbf866c9d2ca4b991\",\"j\":1,\"colours\":[\"blue\",\"green\"]}"
]

In saying so, I feel like the functionality you need is perhaps easier to implement in the application, e.g. when a change is happening, send a notification to the user right away. My thinking is, if you employ triggers/auditing, wouldn’t you need a separate process to monitor such events and fire the notification as well? If this notification is implemented in the application, this monitoring wouldn’t be required - Let me know your thoughts here.

Regards,
Jason

1 Like