update Event

Document Pre- and Post-Images

Starting in MongoDB 6.0, you see a fullDocumentBeforeChange document with the fields before the document was changed (or deleted) if you perform these steps:

1. Enable the new changeStreamPreAndPostImages field for a collection using db.createCollection(), create, or collMod.

2. Set fullDocumentBeforeChange to "required" or "whenAvailable" in db.collection.watch().

Example fullDocumentBeforeChange document in the change stream output:

"fullDocumentBeforeChange" : {
   "_id" : ObjectId("599af247bb69cd89961c986d"),
   "userName" : "alice123",
   "name" : "Alice Smith"
}

For complete examples with the change stream output, see Change Streams with Document Pre- and Post-Images.

Pre- and post-images are not available for a change stream event if the images were:

• Not enabled on the collection at the time of a document update or delete operation.

• Removed after the pre- and post-image retention time set in expireAfterSeconds.

  • The following example sets expireAfterSeconds to 100 seconds on an entire cluster:

    use admin
    db.runCommand( {
       setClusterParameter:
          { changeStreamOptions: {
             preAndPostImages: { expireAfterSeconds: 100 }
          } }
    } )

  • The following example returns the current changeStreamOptions settings, including expireAfterSeconds:

    db.adminCommand( { getClusterParameter: "changeStreamOptions" } )

  • Setting expireAfterSeconds to off uses the default retention policy: pre- and post-images are retained until the corresponding change stream events are removed from the oplog.

  • If a change stream event is removed from the oplog, then the corresponding pre- and post-images are also deleted regardless of the expireAfterSeconds pre- and post-image retention time.

Additional considerations:

• Enabling pre- and post-images consumes storage space and adds processing time. Only enable pre- and post-images if you need them.

• Limit the change stream event size to less than 16 mebibytes. To limit the event size, you can:

  • Limit the document size to 8 megabytes. You can request pre- and post-images simultaneously in the change stream output if other change stream event fields like updateDescription are not large.

  • Request only post-images in the change stream output for documents up to 16 mebibytes if other change stream event fields like updateDescription are not large.

  • Request only pre-images in the change stream output for documents up to 16 mebibytes if:

    • document updates affect only a small fraction of the document structure or content, and

    • do not cause a replace change event. A replace event always includes the post-image.

• To request a pre-image, you set fullDocumentBeforeChange to required or whenAvailable in db.collection.watch(). To request a post-image, you set fullDocument using the same method.

• Pre-images are written to the config.system.preimages collection.

  • The config.system.preimages collection may become large. To limit the collection size, you can set expireAfterSeconds time for the pre-images as shown earlier.

  • Pre-images are removed asynchronously by a background process.

Path Disambiguation

The updateDescription field notes changes made to specific fields in documents by an operation. These field descriptors use dots (.) as path separators and numbers as array indexes, which leads to some ambiguity when it contains field names that use dots or numbers.

When an update event reports changes involving ambiguous fields, the disambiguatedPaths document provides the path key with an array listing each path component.

For example, consider a document that lists people and the towns in which they live:

{
   "name": "Anthony Trollope",
   "home.town": "Oxford",
   "residences": [
      {"0": "Oxford"},
      {"1": "Sunbury"}
   ]
}

• When an update modifies the home.town field from Oxford to London, it produces an update description that looks like this:

  "updateDescription": {
     "updatedFields": {
        "home.town": "London"
     },
     "disambiguatedPaths": {
        "home.town": [ "home.town" ]
     }
  }

  Because the field home.town contains a period, the disambiguatedPaths field shows an array with one value, to indicate that town is not a sub-field of home.

• When an update modifies a value in the residences array to make the same change, it produces an update description that looks like this:

  "updateDescription": {
     "updatedFields": {
        "residences.0.0": "London"
     },
     "disambiguatedPaths": { "residences.0.0": [ "residences", 0, "0" ] }
  }

  The disambiguated paths include an integer 0 to indicate the array index and the string "0" to indicate the field name within the nested document.

There are two cases where disambiguatedPath does not include a numeric field:

• When the first field in the path is a numeric string (i.e. 0.name). This is not ambiguous since the first field cannot be an array index.

• When the numeric string field has leading zeroes (i.e., 0001). This is not ambiguous since an integer cannot have leading zeroes.

Update Operations

The update command can produce different change events (not just update) depending on the actual changes it makes to the collection.

Array Updates

Updates to arrays produce update change events, but the updateDescription.updateFields can show different values.

For example, consider the following document and updates:

db.students.insertOne( { student_id: 1, scores: [ ] } )
db.students.updateOne(
   { student_id: 1 },
   { $push: { scores: 0.85 } }
)
db.students.updateOne(
   { student_id: 1 },
   { $push: { scores: 0.94 } }
)
db.students.updateOne(
   { student_id: 1 },
   { $pull: { scores: 0.94 } }
)

The first update operates on an empty array. Here, the $push produces an update change event where the field is replaced by single-entry array with the given value:

{
   _id: { _data: '82642AD66B000000012B022C0100296E5A10045DC4B11BEA5F4319A8E7CAF46816ED71461E5F6964002B060004' },
   operationType: 'update',
   clusterTime: Timestamp({ t: 1680529003, i: 1 }),
   ns: { db: 'communication_chat', coll: 'students' },
   documentKey: { student_id: 1 },
   updateDescription: {
      updatedFields: { scores: [ 0.85 ] },
      removedFields: [],
      truncatedArrays: []
   }
}

In the second update operation, the array now contains values. The $push adds a new entry in the array. The update change event then shows it as a change on the new position in the array (that is, scores.1):

{
  _id: { _data: '82642AD673000000012B022C0100296E5A10045DC4B11BEA5F4319A8E7CAF46816ED71461E5F6964002B060004' },
  operationType: 'update',
  clusterTime: Timestamp({ t: 1680529011, i: 1 }),
  ns: { db: 'communication_chat', coll: 'students' },
  documentKey: { student_id: 1 },
  updateDescription: {
    updatedFields: { 'scores.1': 0.94 },
    removedFields: [],
    truncatedArrays: []
  }
}

If you run the update operation again to add a third score to the student's record, it would produce an update change event that modifies scores.2.

Removal of array items with the $pull operator produces a change event that shows the new array:

{
  _id: { _data: '82642AD673000000012B022C0100296E5A10045DC4B11BEA5F4319A8E7CAF46816ED71461E5F6964002B060004' },
  operationType: 'update',
  clusterTime: Timestamp({ t: 1680529011, i: 1 }),
  ns: { db: 'communication_chat', coll: 'students' },
  documentKey: { student_id: 1 },
  updateDescription: {
    updatedFields: { scores: [ 0.85 ] },
    removedFields: [],
    truncatedArrays: []
  }
}

Array Truncation

Update operations that reduce the number of elements in arrays through the pipeline updates, such as with the $addFields or $set aggregation stages, show the updated array and new size in the truncatedArrays field.

db.students.insertOne( { student_id: 2, scores: [ 0.85, 0.94, 0.78 ] } )
db.students.updateOne(
   { student_id: 2 },
   [ { $addFields: { scores: [ 0.85, 0.94 ] } } ]
)
db.students.updateOne(
   { student_id: 2 },
   [ { $addFields: { scores: [ 0.85, 0.94, 0.78 ] } } ]
)

The change event from the first update, which used the $addFields stage to remove a value from the scores field shows the change in the truncatedArrays field:

{
  _id: { _data: '82642AD673000000012B022C0100296E5A10045DC4B11BEA5F4319A8E7CAF46816ED71461E5F6964002B060004' },
  operationType: 'update',
  clusterTime: Timestamp({ t: 1680529011, i: 1 }),
  ns: { db: 'communication_chat', coll: 'students' },
  documentKey: { student_id: 2 },
  updateDescription: {
    updatedFields: {},
    removedFields: [],
    truncatedArrays: [ { fields: "scores", newSize: 2 } ]
  }
}

The change event from the second update, which used the $addFields stage to add a value back to the scores field, shows the update in the updatedFields field:

{
  _id: { _data: '82642AD673000000012B022C0100296E5A10045DC4B11BEA5F4319A8E7CAF46816ED71461E5F6964002B060004' },
  operationType: 'update',
  clusterTime: Timestamp({ t: 1680529011, i: 1 }),
  ns: { db: 'communication_chat', coll: 'students' },
  documentKey: { student_id: 2 },
  updateDescription: {
    updatedFields: { scores.2: 0.78 },
    removedFields: [],
    truncatedArrays: []
  }
}