anchor.diff:  
   [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:/docs/faq#avro-converter[Avro Converter], the resulting Avro schems for _each table_ in each _logical source_ have their own evolution and history.
  +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:/docs/faq#avro-converter[Avro Converter], the resulting Avro schemas for _each table_ in each _logical source_ have their own evolution and history.
   ====
   
   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 row was created (since `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.
  
positive.code: 
  |`table.whitelist`
  |_empty string_
  |An optional comma-separated list of regular expressions that match fully-qualified table identifiers for tables to be monitored; any table not included in the whitelist will be excluded from monitoring. Each identifer is of the form _databaseName_._tableName_. By default the connector will monitor every non-system table in each monitored database. May not be used with `table.blacklist`.
  
  |`table.blacklist`
  |_empty string_
  |An optional comma-separated list of regular expressions that match fully-qualified table identifiers for tables to be excluded from monitoring; any table not included in the blacklist will be monitored. Each identifer is of the form _databaseName_._tableName_. May not be used with `table.whitelist`.
  
  |`column.blacklist`
  |_empty string_
  
negative.code: 
  |=======================
  
  The connector also supports _pass-through_ configuration properties that are used when creating the Kafka producer and consumer. Specifically, all connector configuration properties that begin with the `database.history.kafka.producer.` prefix are used (without the prefix) when creating the Kafka producer that writes to the database history, and all those that begin with the prefix `database.history.kafka.consumer.` are used (without the prefix) when creating the Kafka consumer that reads the database history upon connector startup.
  
  For example, the following connector configuration properties can be used to http://kafka.apache.org/documentation.html#security_configclients[secure connections to the Kafka broker]:
  
  