anchor.diff:              }
             ],
             "optional": false,
  -          "name": "io.debezium.connector.mongo.Source",
  +          "name": "io.debezium.connector.mongo.Source", <2>
             "field": "source"
           },
           {
  
positive.code: Partitioning the events by key does mean that all events with the same key always go to the same partition. This ensures that all events for a specific document are always totally ordered.
  
  [[mongodb-events]]
  === Events
  
  All data change events produced by the MongoDB connector have a key and a value.
  
  {prodname} and Kafka Connect are designed around _continuous streams of event messages_, and the structure of these events could potentially change over time if the source of those events changed in structure or if the connector is improved or changed.
  This could be difficult for consumers to deal with, so to make it very easy Kafka Connect makes each event self-contained. Every message key and value has two parts: a _schema_ and _payload_. The schema describes the structure of the payload, while the payload contains the actual data.
  
  [[mongodb-change-events-key]]
  ==== Change event's key
  
  For a given collection, the change event's key contains a single `id` field.
  Its value is the document's identifier represented as string which is derived from the https://docs.mongodb.com/manual/reference/mongodb-extended-json/[MongoDB extended JSON serialization in strict mode]. Consider a connector with a logical name of `fulfillment`, a replica set containing an `inventory` database with a `customers` collection containing documents such as:
  
  [source,json,indent=0]
  ----
    {
  
negative.code:   }
  ----
  
  .Descriptions of _update_ event value fields
  [cols="1,2,7",options="header"]
  |===
  |Item |Field name |Description
  
  |1
  |`op`
  a| Mandatory string that describes the type of operation that caused the connector to generate the event. In this example, `u` indicates that the operation updated a document. 
  
  |2
  |`ts_ms`
  a| Optional field that displays the time at which the connector processed the event. The time is based on the system clock in the JVM running the Kafka Connect task.
  
  |3
  |`patch`
  |Contains the JSON string representation of the actual MongoDB idempotent change to the document. In this example, the update changed the `first_name` field to a new value. +
   +
  An _update_ event value does not contain an `after` field. 
  
  |4
  |`filter`
  |Contains the JSON string representation of the MongoDB selection criteria that was used to identify the document to be updated. 
  
  |5
  |`source`
  a| Mandatory field that describes the source metadata for the event. This field contains the same information as a _create_ event for the same collection, but the values are different since this event is from a different position in the oplog. The source metadata includes: 
  
  * {prodname} version.
  * Name of the connector that generated the event.
  * Logical name of the MongoDB replica set, which forms a namespace for generated events and is used in Kafka topic names to which the connector writes.
  * Names of the collection and database that contain the updated document.
  * If the event was part of a snapshot.
  * Timestamp for when the event occurred and ordinal of the event within the timestamp.
  * Unique identifier of the MongoDB operation, which depends on the version of MongoDB. It is either the `h` field in the oplog event, or a field named `stxnid`, which represents the `lsid` and `txnNumber` fields from the oplog event.
  
  |===
  
  [WARNING]
  ====
  In a {prodname} change event, MongoDB provides the content of the `patch` field. The format of this field depends on the version of the MongoDB database. Consequently, be prepared for potential changes to the format when you upgrade to a newer MongoDB database version. Examples in this document were obtained from MongoDB 3.4, In your application, event formats might be different.
  ====
  
  [NOTE]
  ====
  In MongoDB's oplog, _update_ events do not contain the _before_ or _after_ states of the changed document. Consequently, it is not possible for a {prodname} connector to provide this information. However, MongoDB's oplog contains a document's starting state in _create_ and _read_ events. Downstream consumers of the stream can reconstruct document state by keeping the latest state for each document and comparing the state in a new event with the saved state. {prodname} connector's are not able to keep this state. 
  ====
  
  [id="mongodb-delete-events"]
  ==== _delete_ events
  
  The value in a _delete_ change event has the same `schema` portion as _create_ and _update_ events for the same collection. The `payload` portion in a _delete_ event contains values that are different from _create_ and _update_ events for the same collection. In particular, a _delete_ event contains neither an `after` value nor a `patch` value. Here is an example of a _delete_ event for a document in the `customers` collection: 
  
  [source,json,indent=0,subs="+attributes"]
  ----
  {
      "schema": { ... },
      "payload": {
        "op": "d", <1>
        "ts_ms": 1465495462115, <2>
        "filter": "{\"_id\" : {\"$numberLong\" : \"1004\"}}", <3>
        "source": { <4>
          "version": "{debezium-version}",
          "connector": "mongodb",
          "name": "fulfillment",
          "ts_sec": 1558965508000,
          "snapshot": true,
          "db": "inventory",
          "rs": "rs0",
  