Docs Home → Develop Applications → MongoDB Manual
Change Events![](/docs/v5.3/assets/link.svg)
On this page
Change Events![](/docs/v5.3/assets/link.svg)
The following document represents all possible fields that a change stream response document can have.
{ _id : { <BSON Object> }, "operationType" : "<operation>", "fullDocument" : { <document> }, "ns" : { "db" : "<database>", "coll" : "<collection>" }, "to" : { "db" : "<database>", "coll" : "<collection>" }, "documentKey" : { "_id" : <value> }, "updateDescription" : { "updatedFields" : { <document> }, "removedFields" : [ "<field>", ... ], "truncatedArrays" : [ { "field" : <field>, "newSize" : <integer> }, ... ] }, "clusterTime" : <Timestamp>, "txnNumber" : <NumberLong>, "lsid" : { "id" : <UUID>, "uid" : <BinData> } }
Some fields are only available for certain operations, such as updates. The following table describes each field in the change stream response document:
Field | Type | Description | |||
---|---|---|---|---|---|
document | A BSON object which serves as an identifier for the
change stream event. This value is used as the
The See Resume a Change Stream for an example of resuming a
change stream by | ||||
operationType | string | The type of operation that occurred. Can be any of the following values:
| |||
fullDocument | document | The document created or modified by the For For For | |||
ns | document | The namespace (database and or collection) affected by the event. | |||
ns.db | string | The name of the database. | |||
ns.coll | string | The name of the collection. For | |||
to | document | When operationType : rename , this document displays the new name for
the ns collection. This document is omitted for all other
values of operationType . | |||
to.db | string | The new name of the database. | |||
to.coll | string | The new name of the collection. | |||
documentKey | document | A document that contains the _id of the document created or modified by the insert ,
replace , delete , update operations (i.e. CRUD operations).
For sharded collections, also displays the full shard key for the
document. The _id field is not repeated if it is already a
part of the shard key. | |||
updateDescription | document | A document describing the fields that were updated or removed by the update operation. This document and its fields only appears if the | |||
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. | |||
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: NoteIf the entire array is replaced, the truncations will be
reported under | |||
updateDescription. truncatedArrays. field | string | The name of the truncated field. | |||
updateDescription. truncatedArrays. newSize | integer | The number of elements in the truncated array. | |||
clusterTime | Timestamp | The timestamp from the oplog entry associated with the event. For events that happened as part of a multi-document
transaction, the associated change stream
notifications will have the same On a sharded cluster, events that occur on different shards can
have the same New in version 4.0. | |||
txnNumber | NumberLong | The transaction number. Only present if the operation is part of a multi-document transaction. New in version 4.0. | |||
lsid | Document | The identifier for the session associated with the transaction. Only present if the operation is part of a multi-document transaction. New in version 4.0. |
insert
Event![](/docs/v5.3/assets/link.svg)
The following example illustrates an insert
event:
{ _id: { < Resume Token > }, operationType: 'insert', clusterTime: <Timestamp>, ns: { db: 'engineering', coll: 'users' }, documentKey: { userName: 'alice123', _id: ObjectId("599af247bb69cd89961c986d") }, fullDocument: { _id: ObjectId("599af247bb69cd89961c986d"), userName: 'alice123', name: 'Alice' } }
The documentKey
field includes both the _id
and the userName
field. This indicates that the engineering.users
collection is sharded,
with a shard key on userName
and _id
.
The fullDocument
document represents the version of the document at the
time of the insert.
update
Event![](/docs/v5.3/assets/link.svg)
The following example illustrates an update
event:
{ _id: { < Resume Token > }, operationType: 'update', clusterTime: <Timestamp>, 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>, ns: { db: 'engineering', coll: 'users' }, documentKey: { _id: ObjectId("58a4eb4a30c75625e00d2820") }, updateDescription: { updatedFields: { email: 'alice@10gen.com' }, removedFields: ['phoneNumber'], truncatedArrays: [ { "field" : "vacation_time", "newSize" : 36 } ] }, 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.
replace
Event![](/docs/v5.3/assets/link.svg)
The following example illustrates a replace
event:
{ _id: { < Resume Token > }, operationType: 'replace', clusterTime: <Timestamp>, ns: { db: 'engineering', coll: 'users' }, documentKey: { _id: ObjectId("599af247bb69cd89961c986d") }, fullDocument: { _id: ObjectId("599af247bb69cd89961c986d"), userName: 'alice123', name: 'Alice' } }
A replace
operation uses the update command, and consists of two stages:
Delete the original document with the
documentKey
andInsert the new document using the same
documentkey
The fullDocument
of a replace
event represents the document after the
insert of the replacement document.
delete
Event![](/docs/v5.3/assets/link.svg)
The following example illustrates a delete
event:
{ _id: { < Resume Token > }, operationType: 'delete', clusterTime: <Timestamp>, ns: { db: 'engineering', coll: 'users' }, documentKey: { _id: ObjectId("599af247bb69cd89961c986d") } }
The fullDocument
document is omitted as the document no longer exists at the
time the change stream cursor sends the delete
event to the client.
drop
Event![](/docs/v5.3/assets/link.svg)
New in version 4.0.1.
A drop
event occurs when a collection is dropped from a database. The
following example illustrates a drop
event:
{ _id: { < Resume Token > }, operationType: 'drop', clusterTime: <Timestamp>, ns: { db: 'engineering', coll: 'users' } }
A drop
event leads to an invalidate event
for change streams opened against its ns
collection.
rename
Event![](/docs/v5.3/assets/link.svg)
New in version 4.0.1.
A rename
event occurs when a collection is renamed. The following example
illustrates a rename
event:
{ _id: { < Resume Token > }, operationType: 'rename', clusterTime: <Timestamp>, ns: { db: 'engineering', coll: 'users' }, to: { db: 'engineering', coll: 'people' } }
A rename
event leads to an
invalidate event for change streams opened
against its ns
collection or to
collection.
dropDatabase
Event![](/docs/v5.3/assets/link.svg)
New in version 4.0.1.
A dropDatabase
event occurs when a database is dropped. The following
example illustrates a dropDatabase
event:
{ _id: { < Resume Token > }, operationType: 'dropDatabase', clusterTime: <Timestamp>, ns: { db: 'engineering' } }
A dropDatabase
command generates a
drop event for each collection in
the database before generating a dropDatabase
event for the database.
A dropDatabase
event leads to an
invalidate event for change streams opened
against its ns.db
database.
invalidate
Event![](/docs/v5.3/assets/link.svg)
The following example illustrates an invalidate
event:
{ _id: { < Resume Token > }, operationType: 'invalidate', clusterTime: <Timestamp> }
For change streams opened up against a collection, a drop event, rename event, or dropDatabase event that affects the watched collection leads to an invalidate event.
For change streams opened up against a database, a dropDatabase event that affects the watched database leads to an invalidate event.
invalidate
events close the change stream cursor.
You cannot use resumeAfter
to resume a change stream after an
invalidate event (for example, a collection
drop or rename) closes the stream. Starting in MongoDB 4.2, you can use
startAfter to start a new change
stream after an invalidate event.