update
Event
Summary
update
An
update
event occurs when an operation updates a document in a collection.Note
Disambiguation
To learn more about events that occur when collection options are modified, see the
modify
event.
Description
Field | Type | Description | |||
---|---|---|---|---|---|
_id | Document | A BSON object which serves as an identifier for the
change stream event. This value is used as the
The For an example of resuming a change stream by | |||
clusterTime | Timestamp |
Due to oplog size limits,
multi-document transactions may create multiple
oplog entries. In a transaction, change stream events staged in a given oplog
entry share the same Events with the same To identify events for a single transaction, you can use the
combination of Changed in version 8.0. | |||
collectionUUID | UUID | UUID identifying the collection where the change occurred. New in version 6.0. | |||
documentKey | document | Document that contains the For sharded collections, this field also displays the full shard key
for the document. The | |||
fullDocument | document | The document created or modified by a CRUD operation. This field only appears if you configured the change stream with
For more information, see Lookup Full Document for Update Operations. Changed in version 6.0. Starting in MongoDB 6.0, if you set the | |||
fullDocumentBeforeChange | document | The document before changes were applied by the operation. That is, the document pre-image. This field is available when you enable the New in version 6.0. | |||
lsid | document | The identifier for the session associated with the transaction. Only present if the operation is part of a multi-document transaction. | |||
ns | document | The namespace (database and or collection) affected by the event. | |||
ns.coll | string | The name of the collection where the event occurred. | |||
ns.db | string | The name of the database where the event occurred. | |||
operationType | string | The type of operation that the change notification reports. Returns a value of | |||
updateDescription | document | A document describing the fields that were updated or removed by the update operation. | |||
updateDescription. disambiguatedPaths | document | A document that provides clarification of ambiguous
field descriptors in When the Requires that you set the showExpandedEvents option to New in version 6.1. | |||
updateDescription. removedFields | array | An array of fields that were removed by the update operation. | |||
updateDescription. truncatedArrays | array | An array of documents which record array truncations performed with pipeline-based updates using one or more of the following stages: If the entire array is replaced, the truncations will be reported under updateDescription.updatedFields. | |||
updateDescription. truncatedArrays. field | string | The name of the truncated field. | |||
updateDescription. truncatedArrays. newSize | integer | The number of elements in the truncated array. | |||
updateDescription. updatedFields | document | A document whose keys correspond to the fields that were modified by the update operation. The value of each field corresponds to the new value of those fields, rather than the operation that resulted in the new value. | |||
txnNumber | NumberLong | Together with the lsid, a number that helps uniquely identify a transction. Only present if the operation is part of a multi-document transaction. | |||
wallTime | The server date and time of the database operation. New in version 6.0. |
Behavior
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:
Enable the new
changeStreamPreAndPostImages
field for a collection usingdb.createCollection()
,create
, orcollMod
.Set
fullDocumentBeforeChange
to"required"
or"whenAvailable"
indb.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
to100
seconds on an entire cluster:use admin db.runCommand( { setClusterParameter: { changeStreamOptions: { preAndPostImages: { expireAfterSeconds: 100 } } } } ) The following example returns the current
changeStreamOptions
settings, includingexpireAfterSeconds
:db.adminCommand( { getClusterParameter: "changeStreamOptions" } ) Setting
expireAfterSeconds
tooff
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 megabytes. 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 megabytes 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 megabytes if:
document updates affect only a small fraction of the document structure or content, and
do not cause a
replace
change event. Areplace
event always includes the post-image.
To request a pre-image, you set
fullDocumentBeforeChange
torequired
orwhenAvailable
indb.collection.watch()
. To request a post-image, you setfullDocument
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 setexpireAfterSeconds
time for the pre-images as shown earlier.Pre-images are removed asynchronously by a background process.
Important
Backward-Incompatible Feature
Starting in MongoDB 6.0, if you are using document pre- and post-images
for change streams, you must disable
changeStreamPreAndPostImages for each collection using
the collMod
command before you can downgrade to an earlier
MongoDB version.
Tip
See also:
For change stream events and output, see Change Events.
To watch a collection for changes, see
db.collection.watch()
.For complete examples with the change stream output, see Change Streams with Document Pre- and Post-Images.
Path Disambiguation
New in version 6.1.
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.
Note
The disambiguatedPaths
field is only available on change streams
started with the showExpandedEvents option
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 fromOxford
toLondon
, 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, thedisambiguatedPaths
field shows an array with one value, to indicate thattown
is not a sub-field ofhome
.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.
Example
The following example illustrates an update
event:
{ "_id": { <Resume Token> }, "operationType": "update", "clusterTime": <Timestamp>, "wallTime": <ISODate>, "ns": { "db": "engineering", "coll": "users" }, "documentKey": { "_id": ObjectId("58a4eb4a30c75625e00d2820") }, "updateDescription": { "updatedFields": { "email": "alice@10gen.com" }, "removedFields": ["phoneNumber"], "truncatedArrays": [ { "field" : "vacation_time", "newSize" : 36 } ] } }
The following example illustrates an update
event for change streams
opened with the fullDocument : updateLookup
option:
{ "_id": { <Resume Token> }, "operationType": "update", "clusterTime": <Timestamp>, "wallTime": <ISODate>, "ns": { "db": "engineering", "coll": "users" }, "documentKey": { "_id": ObjectId("58a4eb4a30c75625e00d2820") }, "updateDescription": { "updatedFields": { "email": "alice@10gen.com" }, "removedFields": ["phoneNumber"], "truncatedArrays": [ { "field" : "vacation_time", "newSize" : 36 } ], "disambiguatedPaths": { } }, "fullDocument": { "_id": ObjectId("58a4eb4a30c75625e00d2820"), "name": "Alice", "userName": "alice123", "email": "alice@10gen.com", "team": "replication" } }
The fullDocument
document represents the most current majority-committed
version of the updated document. The fullDocument
document may vary from
the document at the time of the update operation depending on the number of
interleaving majority-committed operations that occur between the update
operation and the document lookup.