anchor.diff:    }
   ----
   
  -When we compare this to the value in the other events, we see a couple of differences in the `payload` section:
  -
  -* The `op` field value is now `d`, signifying that this document was deleted
  -* The `patch` field does not appear
  -* The `after` field does not appear
  -* The `filter` field appears and has the stringified JSON representation of the MongoDB selection criteria used for the delete
  -* 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
  -
  -The MongoDB connector provides one other kind of event. Each _delete_ event is followed by a _tombstone_ event that has the same key as the _delete_ event but a `null` value. This provides Kafka with the information needed to run its link:https://kafka.apache.org/documentation/#compaction[log compaction] mechanism to remove _all_ messages with that key.
  -
  -[NOTE]
  -====
  -All MongoDB connector events are designed to work with link:https://kafka.apache.org/documentation/#compaction[Kafka log compaction], which allows for the removal of older messages as long as at least the most recent message for every key is kept. This is how Kafka can reclaim storage space while ensuring that the topic contains a complete dataset and can be used for reloading key-based state.
  -
  -All MongoDB connector events for a uniquely identified document have exactly the same key, signaling to Kafka that only the latest event be kept. A tombstone event informs Kafka that _all_ messages with that same key can be removed.
  -====
  +.Descriptions of _delete_ event value fields
  +[cols="1,2,7",options="header",subs="+attributes"]
  +|===
  +|Item |Field name |Description
  +
  +|1
  +|`op`
  +a|Mandatory string that describes the type of operation. The `op` field value is `d`, signifying that this document was deleted.
  +
  +|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
  +|`filter`
  +|Contains the JSON string representation of the MongoDB selection criteria that was used to identify the document to be deleted.  
  +
  +|4
  +|`source`
  +a| Mandatory field that describes the source metadata for the event. This field contains the same information as a _create_ or _update_ 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 contained the deleted 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.
  +
  +|===
  +
  +MongoDB connector events are designed to work with link:{link-kafka-docs}/#compaction[Kafka log compaction]. Log compaction enables removal of some older messages as long as at least the most recent message for every key is kept. This lets Kafka reclaim storage space while ensuring that the topic contains a complete data set and can be used for reloading key-based state.
  +
  +[id="mongodb-tombstone-events"]
  +.Tombstone events
  +All MongoDB connector events for a uniquely identified document have exactly the same key. When a document is deleted, the _delete_ event value still works with log compaction because Kafka can remove all earlier messages that have that same key. However, for Kafka to remove all messages that have that key, the message value must be `null`. To make this possible, after {prodname}’s MongoDB connector emits a _delete_ event, the connector emits a special tombstone event that has the same key but a `null` value. A tombstone event informs Kafka that all messages with that same key can be removed.
   
   [[mongodb-transaction-metadata]]
   === Transaction Metadata
  
positive.code: === Example configuration
  
  To use the connector to produce change events for a particular MongoDB replica set or sharded cluster, create a configuration file in JSON.
  When the connector starts, it will perform a snapshot of the collections in your MongoDB replica sets and start reading the replica sets' oplogs, producing events for every inserted, updated, and deleted row.
  Optionally filter out collections that are not needed.
  
  ifdef::community[]
  
negative.code:         }
        ]
      },
      "payload": { <5>
        "id": "1004"
      }
    }
  ----
  
  .Description of change event key
  [cols="1,2,7",options="header"]
  |===
  |Item |Field name |Description
  
  |1
  |`schema`
  |The schema portion of the key specifies a Kafka Connect schema that describes what is in the key's `payload` portion. 
  
  |2
  |`fulfillment.inventory.customers.Key`
  a|Name of the schema that defines the structure of the key's payload. This schema describes the structure of the key for the document that was changed. Key schema names have the format _connector-name_._database-name_._collection-name_.`Key`. In this example: + 
  
  * `fulfillment` is the name of the connector that generated this event. + 
  * `inventory` is the database that contains the collection that was changed. +
  * `customers` is the collection that contains the document that was updated.
  
  |3
  |`optional`
  |Indicates whether the event key must contain a value in its `payload` field. In this example, a value in the key's payload is required. A value in the key's payload field is optional when a document does not have a key.
  
  |4
  |`fields` 
  |Specifies each field that is expected in the `payload`, including each field's name, type, and whether it is required.
  
  |5
  |`payload`
  |Contains the key for the document for which this change event was generated. In this example, the key contains a single `id` field of type `string` whose value is `1004`.
  
  |===
  
  This example uses a document with an integer identifier, but any valid MongoDB document identifier works the same way, including a document identifier. For a document identifier, an event key's `payload.id` value is a string that represents the updated document's original `_id` field as a MongoDB extended JSON serialization that uses strict mode. The following table provides examples of how different types of `_id` fields are represented. 
  
  .Examples of representing document `_id` fields in event key payloads
  [options="header",role="code-wordbreak-col2 code-wordbreak-col3"]
  |===
  |Type    |MongoDB `_id` Value|Key's payload
  |Integer |1234|`{ "id" : "1234" }`
  |Float   |12.34|`{ "id" : "12.34" }`
  |String  |"1234"|`{ "id" : "\"1234\"" }`
  |Document|`{ "hi" : "kafka", "nums" : [10.0, 100.0, 1000.0] }`|`{ "id" : "{\"hi\" : \"kafka\", \"nums\" : [10.0, 100.0, 1000.0]}" }`
  |`ObjectId|ObjectId("596e275826f08b2730779e1f")``|`{ "id" : "{\"$oid\" : \"596e275826f08b2730779e1f\"}" }`
  |Binary  |`BinData("a2Fma2E=",0)`|`{ "id" : "{\"$binary\" : \"a2Fma2E=\", \"$type\" : \"00\"}" }`
  |===
  
  [[mongodb-change-events-value]]
  ==== Change event values
  
  The value in a change event is a bit more complicated than the key. Like the key, the value has a `schema` section and a `payload` section. The `schema` section contains the schema that describes the `Envelope` structure of the `payload` section, including its nested fields. Change events for operations that create, update or delete data all have a value payload with an envelope structure. 
  
  Consider the same sample document that was used to show an example of a change event key: 
  
  
  .Example document
  [source,json,indent=0]
  ----
    {
      "_id": 1004,
      "first_name": "Anne",
      "last_name": "Kretchmar",
      "email": "annek@noanswer.org"
    }
  ----
  
  The value portion of a change event for a change to this document is described for each event type: 
  
  * <<mongodb-create-events,_create_ events>>
  * <<mongodb-update-events,_update_ events>>
  * <<mongodb-delete-events,_delete_ events>>
  
  [id="mongodb-create-events"]
  ==== _create_ events
  
  The following example shows the value portion of a change event that the connector generates for an operation that creates data in the `customers` collection: 
  
  [source,json,options="nowrap",indent=0,subs="+attributes"]
  ----
  {
      "schema": { <1>
        "type": "struct",
        "fields": [
          {
            "type": "string",
            "optional": true,
            "name": "io.debezium.data.Json", <2>
            "version": 1,
            "field": "after"
          },
          {
            "type": "string",
            "optional": true,
            "name": "io.debezium.data.Json", <2>
            "version": 1,
            "field": "patch"
          },
          {
            "type": "string",
            "optional": true,
            "name": "io.debezium.data.Json", <2>
            "version": 1,
            "field": "filter"
          },
  