dropDatabase Event
Synopsis
Description
Field  | Type  | Description  | |||
|---|---|---|---|---|---|
  | 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   | |||
  | 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  On sharded clusters, events with the same  To identify events for a single transaction, you can use the
combination of   | |||
  | document  | The identifier for the session associated with the transaction. Only present if the operation is part of a multi-document transaction.  | |||
  | document  | The namespace (database and or collection) affected by the event.  | |||
  | string  | The name of the database where the event occurred.  | |||
  | string  | The type of operation that the change notification reports. Returns a value of   | |||
  | 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.  | |||
  | The server date and time of the database operation.  New in version 6.0.  | 
Example
The following example illustrates a dropDatabase event:
{    "_id": { <Resume Token> },    "operationType": "dropDatabase",    "clusterTime": <Timestamp>,    "wallTime": <ISODate>,    "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 own ns.db database.