Stitch update Triggers (updatedFields in trigger message)

MongoDB Atlas App Services & Realm Atlas Triggers & Functions
1

Hi,
I am using mongo update triggers.
When I update one field inside an object, in the trigger message updatedFields I see the full object, even though only 1 field inside this got updated, Is it possible to see just that updated field and not the whole object?

Example:

Initial Doc:

{
  "_id": "someId"
  "fullName": {
      "first": "matt"
      "last": "hope"
   }
...
}

Lets say I update fullName.first to be “will”. (I am using $merge to do this from one collection to the triggerCollection, not sure if that makes any difference).
In the trigger message details, in the updateDescription.updatedFields I see:

"fullName": {
      "first": "will"
      "last": "hope"
   }

Is it possible in the updateDescription.updatedFields to see just the updated field and not the whole object?
So the following:

"fullName": {
      "first": "will"
   }

Thanks,
Matt

2

Hi @HopeM welcome to the community!

Could you please share the aggregation that’s writing to triggerCollection?

3

Hopefully this is enough… (the match query has no relevance here)

db.getCollection('students')..aggregate([
    {some match query},
    {"$merge": "triggerCollection"}
])

So lets say I update the fullName.first in the doc in the students collection… then run that aggregation
thus updating the corresponding doc in the triggerCollection. Then causing the update trigger change event to occur.

4

Have you tried using the on option for $merge to ensure that it’s updating any existing doc in triggerCollection rather than creating a new one?

5

I am using the default of “_id”, It is definitely updating the correct records and not creating new ones though.

6

I’m seeing a different behaviour. I set up a similar trigger, and when I update the first name, this is what I see in the trigger’s log for the changeEvent:
{\"_id\":{\"_data\":\"82605E074B0000009C2B022C0100296E5A1004BF0C5A1CEA7D4178AF7F4F58A773FDCE46645F69640064605E04A993D628CC1DC7FA740004\"},\"operationType\":\"update\",\"clusterTime\":{\"$timestamp\":{\"t\":1616774987,\"i\":156}},\"fullDocument\":{\"_id\":\"605e04a993d628cc1dc7fa74\",\"first\":\"cecil\",\"last\":\"morgan\"},\"ns\":{\"db\":\"forum\",\"coll\":\"triggerCollection\"},\"documentKey\":{\"_id\":\"605e04a993d628cc1dc7fa74\"},\"updateDescription\":{\"updatedFields\":{\"first\":\"cecil\"},\"removedFields\":[]}}

Only first is appearing in updateDescription.

What command are you using to update the students collection?

7

I am using $merge to update the triggerCollection collection (collection upon which I have the triggers listening).

Sorry if I am not being clear… hopefully the below may help:

  • So first of all I update the record in students collection (it shouldn’t matter what operation i use to update here as there are no triggers on this collection)…
  • Then I run the aggregation query (mentioned previously) on the students collection … and the final line $merge will combine documents with matching _id with the already existing record in the triggerCollection collection (this is the collection upon which the mongo triggers are listening to).
  • So any docs that get updated as a result of this operation will cause a change event to occur.
  • And when looking at this change event the updateDescription.updatedFields contains "fullName": {"first": "will", "last": "hope"} even though I only changed the fullName.first field.

Hope that makes sense.

8

Hi @HopeM that makes sense. I’ve gone through similar steps but see only first appearing in updatedFields and so I’m trying to figure out where we’re diverging. This is my pipleline…

[{
    $match: {}
}, {
    $merge: {
        into: 'triggerCollection'
    }
}]

In my function, I print to the console: console.log(JSON.stringify(changeEvent.updatedFields)); and this is the outut:

"{\"updatedFields\":{\"first\":\"ted\"},\"removedFields\":[]}"

The last attribute (which didn’t change) isn’t included.

9

Hi @Andrew_Morgan that looks like what I am trying… I am going to spend some time today having a play around, if I notice anything that is different in what I am doing or find the problem, I will update you.

Thank you for your help so far.

10

Hi @Andrew_Morgan,

I spent a while yesterday playing around trying various things… suffice to say nothing seemed to work or shed any light on this issue.

Your aggregation pipeline is pretty much exactly what i’m doing, with the $merge step.
And like I said previously I am getting both fields under fullName come through in updated fields even though I only update one.

"updateDescription": {
      "updatedFields": {
        "fullName": {"first": "will", "last": "hope"}
      }
}

So I am not sure what the difference could potentially be.
Could it possibly be to do with a specific mongo version? I am using version 4.2.12

11

I’m using 4.4.4 and so it might be worth upgrading to see if that changes things.

12

Okay, I have tested on 4.4.4 now and it’s the same result.

Not sure where to go from here.

13

@HopeM Just spotted what we’re doing differently. I had first and last as top-level fields. If I embed them within fullName then I get the same behavior as you do.

14

Aha okay at least we’re on the same page now…

So my question now is - Is this expected behaviour for embedded fields?

15

This has to do with the way update operation works as $merge basically turns into an update internally.

By default the behavior of $merge is to merge fields at the top level. So your update basically becomes:

{"$set":{"fullName":{"first":"Asya","last":"Kamsky"}}}

If the entire subdocument matched, then it would be a noop, but when any of its subfields don’t match it becomes an update of the fullName field. That’s the way $merge currently works, so there’s no way for you to only get the subfield that was changed at the moment.

Asya

2 Likes
16

Okay, that’s exactly what I wanted to get to the bottom of!

Thanks Asya.

17

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