anchor.diff:    }
   }
   ----
  -<1> The `schema` portion of this event’s _value_ shows the schema for the envelope, the schema for the source structure (which is specific to the MySQL connector and reused across all events), and the table-specific schemas for the `before` and `after` fields.
  +
  +.Descriptions of _create_ event value fields
  +[cols="1,2,7",options="header"]
  +|===
  +|Item |Field name |Description
  +
  +|1
  +|`schema`
  +|The value's schema, which describes the structure of the value's payload. A change event's value schema is the same in every change event that the connector generates for a particular table. 
  +
  +|2
  +|`name`
  +a|In the `schema` section, each `name` field specifies the schema for a field in the value's payload. In this example: 
  +
  +* `mysql-server-1.inventory.customers.Value` is the schema for the payload's `before` and `after` fields. This schema is specific to the `customers` table.
  +
  +* `io.product.connector.mysql.Source` is the schema for the payload's `source` field. This schema is specific to the MySQL connector. The connector uses it for all events that it generates. 
  +
  +* `mysql-server-1.inventory.customers.Envelope` is the schema for the overall structure of the payload, where `mysql-server-1` is the connector name, `inventory` is the database, and `customers` is the table.
  +
   ifdef::community[]
  -+
  -[TIP]
  -====
  -The names of the schemas for the `before` and `after` fields are of the form `<logicalName>.<tableName>.Value`, and thus are entirely independent from all other schemas for all other tables. This means that when using the {link-prefix}:{link-avro-serialization}[Avro Converter], the resulting Avro schemas for each table in each logical source have their own evolution and history.
  +Names of schemas for `before` and `after` fields are of the form `_logicalName_._tableName_.Value`, which ensures that the schema name is unique in the database. This means that when using the {link-prefix}:{link-avro-serialization}[Avro converter], the resulting Avro schema for each table in each logical source has its own evolution and history.
  +endif::community[]
  +
  +|3
  +|`payload`
  +|The value's actual data. This is the information that the change event is providing. 
  +
  +ifdef::community[]
  +It may appear that the JSON representations of the events are much larger than the rows they describe. This is because the JSON representation must include the schema and the payload portions of the message.
  +However, by using the {link-prefix}:{link-avro-serialization}[Avro converter], you can significantly decrease the size of the messages that the connector streams to Kafka topics.
   ====
   endif::community[]
   
  -<2> The `payload` portion of this event’s _value_ shows the information in the event, namely that it is describing that the row was created (because `op=c`), and that the `after` field value contains the values of the new inserted row's `id`, `first_name`, `last_name`, and `email` columns.
  -ifdef::community[]
  -+
  -[TIP]
  -====
  -It may appear that the JSON representations of the events are much larger than the rows they describe. This is because the JSON representation must include the schema and the payload portions of the message.
  -However, by using the {link-prefix}:{link-avro-serialization}[Avro Converter], you can dramatically decrease the size of the actual messages written to the Kafka topics.
  -====
  -endif::community[]
  -
  -=== Update change event value
  -
  -The value of an _update_ change event on the `customers` table has the exact same schema as a _create_ event. The payload is structured the same, but holds different values. Here is an example (formatted for readability):
  +|4
  +|`op`
  +a| Mandatory string that describes the type of operation that caused the connector to generate the event. In this example, `c` indicates that the operation created a row. Valid values are: 
  +
  +* `c` = create
  +* `u` = update
  +* `d` = delete
  +* `r` = read (applies to only snapshots)
  +
  +|5
  +|`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.
  +
  +|6
  +|`before`
  +| An optional field that specifies the state of the row before the event occurred. When the `op` field is `c` for create, as it is in this example, the `before` field is `null` since this change event is for new content. 
  +
  +|7
  +|`after`
  +| An optional field that specifies the state of the row after the event occurred. In this example, the `after` field contains the values of the new row's `id`, `first_name`, `last_name`, and `email` columns.
  +
  +|8
  +|`source`
  +a| Mandatory field that describes the source metadata for the event. The `source` structure shows information about MySQL’s record of this change, which provides traceability. It also has information you can use to compare to other events in this and other topics to know whether this event occurred before, after, or as part of the same MySQL commit as other events. The source metadata includes: 
  +
  +* {prodname} version
  +* Connector name
  +* binlog name where the event was recorded
  +* binlog position
  +* Row within the event
  +* If the event was part of a snapshot
  +* Name of the database and table that contain the new row
  +* ID of the MySQL thread that created the event (non-snapshot only)
  +* MySQL server ID (if available)
  +* Timestamp
  +
  +If the {link-prefix}:{link-mysql-connector}#enable-query-log-events-for-cdc_{context}[`binlog_rows_query_log_events`] MySQL configuration option is enabled and the connector configuration `include.query` property is enabled, the `source` field also provides the `query` field, which contains the original SQL statement that caused the change event.
  +
  +|===
  +
  +[id="mysql-update-events"]
  +=== _update_ events
  +
  +The value of a change event for an update in the sample `customers` table has the same schema as a _create_ event for that table. Likewise, the event value's payload has the same structure. However, the event value payload contains different values in an _update_ event. Here is an example of a change event value in an event that the connector generates for an update in the `customers` table: 
   
   [source,json,options="nowrap",subs="+attributes"]
   ----
  
positive.code:       }
      ],
      "optional": false,
      "name": "mysql-server-1.inventory.customers.Envelope"
    },
    "payload": { // <2>
      "op": "c",
      "ts_ms": 1465491411815,
      "before": null,
      "after": {
        "id": 1004,
        "first_name": "Anne",
        "last_name": "Kretchmar",
        "email": "annek@noanswer.org"
      },
      "source": {
        "version": "{debezium-version}",
        "connector": "mysql",
        "name": "mysql-server-1",
  
negative.code:       "query": "UPDATE customers SET first_name='Anne Marie' WHERE id=1004"
      },
      "op": "u", // <4>
      "ts_ms": 1465581029523 
    }
  }
  ----
  
  .Descriptions of _update_ event value fields
  [cols="1,2,7",options="header"]
  |===
  |Item |Field name |Description
  
  |1
  |`before`
  |An optional field that specifies the state of the row before the event occurred. In an _update_ event value, the `before` field contains a field for each table column and the value that was in that column before the database commit. In this example, the `first_name` value is `Anne.`
  
  |2
  |`after`
  | An optional field that specifies the state of the row after the event occurred. You can compare the `before` and `after` structures to determine what the update to this row was. In the example, the `first_name` value is now `Anne Marie`. 
  
  |3
  |`source`
  a|Mandatory field that describes the source metadata for the event. The `source` field structure has the same fields as in a _create_ event, but some values are different, for example, the sample _update_ event is from a different position in the binlog. The source metadata includes: 
  
  * {prodname} version
  * Connector name
  * binlog name where the event was recorded
  * binlog position
  * Row within the event
  * If the event was part of a snapshot
  * Name of the database and table that contain the updated row
  * ID of the MySQL thread that created the event (non-snapshot only)
  * MySQL server ID (if available)
  * Timestamp
  
  If the {link-prefix}:{link-mysql-connector}#enable-query-log-events-for-cdc_{context}[`binlog_rows_query_log_events`] MySQL configuration option is enabled and the connector configuration `include.query` property is enabled, the `source` field also provides the `query` field, which contains the original SQL statement that caused the change event.
  
  |4
  |`op`
  a|Mandatory string that describes the type of operation. In an _update_ event value, the `op` field value is `u`, signifying that this row changed because of an update.
  
  |===
  
  [NOTE]
  ====
  Updating the columns for a row's primary/unique key changes the value of the row's key. When a key changes, {prodname} outputs _three_ events: a `DELETE` event and a {link-prefix}:{link-mysql-connector}#mysql-tombstone-events[tombstone event] with the old key for the row, followed by an event with the new key for the row. Details are in the next section. 
  ====
  
  [id="mysql-primary-key-updates"]
  === Primary key updates
  
  An `UPDATE` operation that changes a row's primary key field(s) is known
  as a primary key change. For a primary key change, in place of sending an `UPDATE` event record, the connector sends a `DELETE` event record for the old key and a `CREATE` event record for the new (updated) key. These events have the usual structure and content, and in addition, each one has a message header related to the primary key change: 
  
  * The `DELETE` event record has `__debezium.newkey` as a message header. The value of this header is the new primary key for the updated row.
  
  * The `CREATE` event record has `__debezium.oldkey` as a message header. The value of this header is the previous (old) primary key that the updated row had.
  
  [id="mysql-delete-events"]
  === _delete_ events
  
  The value in a _delete_ change event has the same `schema` portion as _create_ and _update_ events for the same table. The `payload` portion in a _delete_ event for the sample `customers` table looks like this:  
  
  [source,json,options="nowrap",subs="+attributes"]
  ----
  