anchor.diff:  
   Commit logs' binary data are deserialized with Cassandra's CommitLogReader and CommitLogReadHandler. Each deserialized object is called a `mutation` in Cassandra. A `mutation` contains one or more change events.
   
  -As the Cassandra connector reads the commit log, it transform the log events into Debezium _create_, _update_, or _delete_ events that include the position in the commit log where the event was found. The Cassandra connector encode these change events with Avro and publish them to the appropriate Kafka topics.
  +As the Cassandra connector reads the commit log, it transform the log events into Debezium _create_, _update_, or _delete_ events that include the position in the commit log where the event was found. The Cassandra connector encode these change events with Kafka Connect converters and publish them to the appropriate Kafka topics.
   
   [[limitations-of-commit-logs]]
   === Limitations of Commit Logs
  
positive.code: 
  **TODO**: it may be possible to reactively refresh schema whenever an unexpect column appears in a mutation to improve schema change detection; worth looking into.
  
  When sending a message to a topic t, the Avro schema for the key and the value will be automatically registered in the Confluent Schema Registry under the subject t-key and t-value, respectively, if the compatibility test passes. Although it is possible to replay a history of all table schemas via the Schema Registry, only the latest schema of each table is used to generate CDC events.
  
  **TODO**: look into if it's possible to leverage schema history to rebuild schema that exist at the specific position in the commit log, rather than the current schema, when restarting the connector. I don't think it's possible right now, because writes to Cassandra node are not received in order.
  
  
negative.code: 
  As described above, the Cassandra connector represents the changes to rows with events that are structured like the table in which the row exist. The event contains a field for each column value, and how that value is represented in the event depends on the Cassandra data type of the column. This section describes this mapping.
  
  The following table describes how the connector maps each of the Cassandra data types to an Kafka Connect data type.
  
  [cols="30%a, 30%a, 40%a",options="header"]
  |=======================
  