anchor.diff:              {
                 "type": "int64",
                 "optional": false,
  -              "field": "ts_ms"
  +              "field": "ts_sec"
               },
               {
                 "type": "boolean",
  
positive.code:         }
        ]
      },
      "payload": {
        "id": "1004"
      }
    }
  ----
  
  The `schema` portion of the key contains a Kafka Connect schema describing what is in the payload portion. In this case, it means that the `payload` value is not optional, is a structure defined by a schema named `fulfillment.inventory.customers.Key`, and has one required field named `id` of type `string`. If you look at the value of the key's `payload` field, you can see that it is indeed a structure (which in JSON is just an object) with a single `id` field, whose value is a string containing the integer `1004`.
  
  This example used a document with an integer identifier, but any valid MongoDB document identifier (including documents) will work. The value of the `id` field in the payload will simply be a string representing a MongoDB extended JSON serialization (strict mode) of the original document's `_id` field. Find below a few examples showing how `_id` fields of
  different types will get encoded as the event key's payload:
  
  [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\"}" }`
  |===
  
  ifdef::community[]
  [WARNING]
  ====
  The MongoDB connector ensures that all Kafka Connect _schema names_ are http://avro.apache.org/docs/current/spec.html#names[valid Avro schema names]. This means that the logical server name must start with Latin letters or an underscore (e.g., [a-z,A-Z,\_]), and the remaining characters in the logical server name and all characters in the database and collections names must be Latin letters, digits, or an underscore (e.g., [a-z,A-Z,0-9,\_]). If not, then all invalid characters will automatically be replaced with an underscore character.
  
  This can lead to unexpected conflicts in schemas names when the logical server name, database names, and collection names contain other characters, and the only distinguishing characters between collection full names are invalid and thus replaced with underscores. The connector attempts to produce an exception in this such cases, but only when the conflicts exist between schemas used within a single connector.
  ====
  endif::community[]
  
  [[mongodb-change-events-value]]
  ==== Change event's value
  
  The value of the change event message is a bit more complicated.
  Like the key message, it has a _schema_ section and _payload_ section.
  The payload section of every change event value produced by the MongoDB connector has an _envelope_ structure with the following fields:
  
  * `op` is a mandatory field that contains a string value describing the type of operation. Values for the MongoDB connector are `c` for create (or insert), `u` for update, `d` for delete, and `r` for read (in the case of a snapshot).
  * `after` is an optional field that if present contains the state of the document _after_ the event occurred. MongoDB's oplog entries only contain the full state of a document for _create_ events, so these are the only events that contain an _after_ field.
  * `source` is a mandatory field that contains a structure describing the source metadata for the event, which in the case of MongoDB contains several fields: the {prodname} version, the logical name, the replica set's name, the namespace of the collection, the MongoDB timestamp (and ordinal of the event within the timestamp) at which the event occurred, a unique identifier of the MongoDB operation (depending on the version of MongoDB, either the `h` field in the oplog event, or a field named `stxnid`, representing the `lsid` and `txnNumber` fields from the oplog event), and the `snapshot` flag if the event resulted during a snapshot.
  * `ts_ms` is optional and if present contains the time (using the system clock in the JVM running the Kafka Connect task) at which the connector processed the event.
  
  And of course, the _schema_ portion of the event message's value contains a schema that describes this envelope structure and the nested fields within it.
  
  Let's look at what a _create_/_read_ event value might look like for our `customers` collection:
  
  [source,json,indent=0,subs="attributes"]
  ----
  {
      "schema": {
        "type": "struct",
        "fields": [
          {
            "type": "string",
            "optional": true,
            "name": "io.debezium.data.Json",
            "version": 1,
            "field": "after"
          },
          {
            "type": "string",
            "optional": true,
            "name": "io.debezium.data.Json",
            "version": 1,
            "field": "patch"
          },
          {
            "type": "string",
            "optional": true,
            "name": "io.debezium.data.Json",
            "version": 1,
            "field": "filter"
          },
  
negative.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]]
  === Data change events
  
  The {prodname} MongoDB connector generates a data change event for each document-level operation that inserts, updates, or deletes data. Each event contains a key and a value. The structure of the key and the value depends on the collection that was changed. 
  
  {prodname} and Kafka Connect are designed around _continuous streams of event messages_. However, the structure of these events may change over time, which can be difficult for consumers to handle. To address this, each event contains the schema for its content or, if you are using a schema registry, a schema ID that a consumer can use to obtain the schema from the registry. This makes each event self-contained. 
  
  The following skeleton JSON shows the basic four parts of a change event. However, how you configure the Kafka Connect converter that you choose to use in your application determines the representation of these four parts in change events. A `schema` field is in a change event only when you configure the converter to produce it. Likewise, the event key and event payload are in a change event only if you configure a converter to produce it. If you use the JSON converver and you configure it to produce all four basic change event parts, change events have this structure: 
  
  [source,json,index=0]
  ----
  {
   "schema": { //<1>
     ...
    },
   "payload": { //<2>
     ...
   },
   "schema": { //<3> 
     ...
   },
   "payload": { //<4>
     ...
   },
  }
  ----
  
  .Overview of change event basic content
  [cols="1,2,7",options="header"]
  |===
  |Item |Field name |Description
  
  |1
  |`schema`
  |The first `schema` field is part of the event key. It specifies a Kafka Connect schema that describes what is in the event key's `payload` portion. In other words, the first `schema` field describes the structure of the key for the document that was changed. 
  
  |2
  |`payload`
  |The first `payload` field is part of the event key. It has the structure described by the previous `schema` field and it contains the key for the document that was changed. 
  
  |3
  |`schema`
  |The second `schema` field is part of the event value. It specifies the Kafka Connect schema that describes what is in the event value's `payload` portion. In other words, the second `schema` describes the structure of the document that was changed. Typically, this schema contains nested schemas. 
  
  |4
  |`payload`
  |The second `payload` field is part of the event value. It has the structure described by the previous `schema` field and it contains the actual data for the document that was changed.
  
  |===
  
  By default, the connector streams change event records to topics with names that are the same as the event's originating collection. See {link-prefix}:{link-mongodb-connector}#mongodb-topic-names[topic names].
  
  [WARNING]
  ====
  The MongoDB connector ensures that all Kafka Connect schema names adhere to the link:http://avro.apache.org/docs/current/spec.html#names[Avro schema name format]. This means that the logical server name must start with a Latin letter or an underscore, that is, a-z, A-Z, or \_. Each remaining character in the logical server name and each character in the database and collection names must be a Latin letter, a digit, or an underscore, that is, a-z, A-Z, 0-9, or \_. If there is an invalid character it is replaced with an underscore character.
  
  This can lead to unexpected conflicts if the logical server name, a database name, or a collection name contains invalid characters, and the only characters that distinguish names from one another are invalid and thus replaced with underscores.
  ====
  
  [[mongodb-change-events-key]]
  ==== Change event keys
  
  A change event's key contains the schema for the changed document's key and the changed document's actual key. For a given collection, both the schema and its corresponding payload contain a single `id` field.
  The value of this field is the document's identifier represented as a string that is derived from link:https://docs.mongodb.com/manual/reference/mongodb-extended-json/[MongoDB extended JSON serialization strict mode].
  
  Consider a connector with a logical name of `fulfillment`, a replica set containing an `inventory` database, and a `customers` collection that contains documents such as the following. 
  
  .Example document
  [source,json,indent=0]
  ----
    {
  