anchor.diff:    }
   ----
   
  -When we compare this to the value in the _insert_ event, we see a couple of differences in the `payload` section:
  -
  -* The `op` field value is now `u`, signifying that this document changed because of an update
  -* The `patch` field appears and has the stringified JSON representation of the actual MongoDB idempotent change to the document, which in this example involves setting the `first_name` field to a new value
  -* The `filter` field appears and has the stringified JSON representation of the MongoDB selection criteria used for the update
  -* The `after` field no longer appears
  -* The `source` field structure has the same fields as before, but the values are different since this event is from a different position in the oplog
  -* The `ts_ms` shows the timestamp that {prodname} processed this event
  +.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]
   ====
  -The content of the patch field is provided by MongoDB itself and its exact format depends on the specific database version.
  -You should therefore be prepared for potential changes to the format when upgrading the MongoDB instance to a new version.
  -
  -All examples in this document were obtained from MongoDB 3.4 and might differ if you use a different one.
  +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]
   ====
  -Update events in MongoDB's oplog do not have the _before_ or _after_ states of the changed document, so there's no way for the connector to provide this information.
  -However, because _create_ or _read_ events _do_ contain the starting state, downstream consumers of the stream can actually fully-reconstruct the state by keeping the latest state for each document and applying each event to that state. {prodname} connector's are not able to keep such state, so it is not able to do this.
  -====
  -
  -So far, you have seen samples of _create_/_read_ and _update_ events. The following sample shows the value of a _delete_ event for the same collection.
  -The value of a _delete_ event on this collection has the exact same _schema_, and its payload is structured the same but it holds different values.
  -In particular, a delete event does not have an `after` value nor a `patch` value:
  -
  -[source,json,indent=0,subs="attributes"]
  +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",
  -      "ts_ms": 1465495462115,
  -      "filter": "{\"_id\" : {\"$numberLong\" : \"1004\"}}",
  -      "source": {
  +      "op": "d", <1>
  +      "ts_ms": 1465495462115, <2>
  +      "filter": "{\"_id\" : {\"$numberLong\" : \"1004\"}}", <3>
  +      "source": { <4>
           "version": "{debezium-version}",
           "connector": "mongodb",
           "name": "fulfillment",
  -        "ts_ms": 1558965508000,
  +        "ts_sec": 1558965508000,
           "snapshot": true,
           "db": "inventory",
           "rs": "rs0",
  
positive.code:         }
        ],
        "optional": false,
        "name": "dbserver1.inventory.customers.Envelope"
        },
      "payload": {
        "after": "{\"_id\" : {\"$numberLong\" : \"1004\"},\"first_name\" : \"Anne\",\"last_name\" : \"Kretchmar\",\"email\" : \"annek@noanswer.org\"}",
        "patch": null,
        "source": {
          "version": "{debezium-version}",
          "connector": "mongodb",
          "name": "fulfillment",
          "ts_ms": 1558965508000,
          "snapshot": true,
          "db": "inventory",
          "rs": "rs0",
          "collection": "customers",
          "ord": 31,
          "h": 1546547425148721999
        },
        "op": "r",
        "ts_ms": 1558965515240
      }
    }
  ----
  
  If we look at the `schema` portion of this event's _value_, we can see the schema for the _envelope_ is specific to the collection, and the schema for the `source` structure (which is specific to the MongoDB connector and reused across all events). Also note that the `after` value is always a string, and that by convention it will contain a JSON representation of the document.
  
  If we look at the `payload` portion of this event's _value_, we can see the information in the event, namely that it is describing that the document was read as part of an snapshot (since `op=r` and `snapshot=true`), and that the `after` field value contains the JSON string representation of the document.
  
  [NOTE]
  ====
  It may appear that the JSON representations of the events are much larger than the rows they describe. This is true, because the JSON representation must include the _schema_ and the _payload_ portions of the message.
  ifdef::community[]
  It is possible and even recommended to use the link:/docs/faq/#avro-converter[Avro Converter] to dramatically decrease the size of the actual messages written to the Kafka topics.
  endif::community[]
  ====
  
  The value of an _update_ change event on this collection will actually have the exact same _schema_, and its payload is structured the same but will hold different values. Specifically, an update event will not have an `after` value and will instead have a `patch` string containing the JSON representation of the idempotent update operation and a `filter` string containing the JSON representation of the selection criteria for the update.  The `filter` string can include multiple shard key fields for sharded collections. Here's an example:
  
  [source,json,indent=0,subs="attributes"]
  ----
  {
      "schema": { ... },
      "payload": {
        "op": "u",
        "ts_ms": 1465491461815,
        "patch": "{\"$set\":{\"first_name\":\"Anne Marie\"}}",
        "filter": "{\"_id\" : {\"$numberLong\" : \"1004\"}}",
        "source": {
          "version": "{debezium-version}",
          "connector": "mongodb",
          "name": "fulfillment",
          "ts_ms": 1558965508000,
          "snapshot": true,
          "db": "inventory",
          "rs": "rs0",
  
negative.code:   }
  ----
  
  .Example change event key
  Every change event that captures a change to the `customers` collection has the same event key schema. For as long as the `customers` collection has the previous definition, every change event that captures a change to the `customers` collection has the following key structure. In JSON, it looks like this:
  
  [source,json,indent=0]
  ----
    {
      "schema": { <1>
        "type": "struct",
        "name": "fulfillment.inventory.customers.Key" <2>
        "optional": false, <3>
        "fields": [ <4>
          {
            "field": "id",
            "type": "string",
  