anchor.diff:  transforms.Reroute.key.field.replacement=$2
   ----
   
  -With this configuration, suppose that the default destination topic names are: 
  +With this configuration, suppose that the default destination topic names are:
   
   `myserver.mydb.customers_shard1` +
   `myserver.mydb.customers_shard2` +
  
positive.code: // Title: Use case for routing {prodname} records to topics that you specify
  == Use case
  
  The default behavior is that a {prodname} connector sends each change event record to a topic whose name is formed from the name of the database and the name of the table in which the change was made. In other words, a topic receives records for one physical table. When you want a topic to receive records for more than one physical table, you must configure the {prodname} connector to re-route the records to that topic. 
  
  .Logical tables
  
  A logical table is a common use case for routing records for multiple physical tables to one topic. In a logical table, there are multiple physical tables that all have the same schema. For example, sharded tables have the same schema. A logical table might consist of two or more sharded tables: `db_shard1.my_table` and `db_shard2.my_table`. The tables are in different shards and are physically distinct but together they form a logical table. 
  You can re-route change event records for tables in any of the shards to the same topic.
  
  .Partitioned PostgreSQL tables
  
  When the {prodname} PostgreSQL connector captures changes in a partitioned table, the default behavior is that change event records are routed to a different topic for each partition. To emit records from all partitions to one topic, configure the topic routing SMT. Because each key in a partitioned table is guaranteed to be unique, configure {link-prefix}:{link-topic-routing}#by-logical-table-router-key-enforce-uniqueness[`key.enforce.uniqueness=false`] so that the SMT does not add a key field to ensure unique keys. The addition of a key field is default behavior. 
  
  // Type: concept
  // ModuleID: example-of-routing-debezium-records-for-multiple-tables-to-one-topic
  // Title: Example of routing {prodname} records for multiple tables to one topic
  == Example
  
  To route change event records for multiple physical tables to the same topic, configure the topic routing transformation in the Kafka Connect configuration for the {prodname} connector. Configuration of the topic routing SMT requires you to specify regular expressions that determine: 
  
  * The tables for which to route records. These tables must all have the same schema. 
  * The destination topic name.
  
  For example, configuration in a `.properties` file looks like this: 
  
  [source]
  ----
  
negative.code: 
  toc::[]
  
  Each Kafka record that contains a data change event has a default destination topic. If you need to, you can re-route records to topics that you specify before the records reach the Kafka Connect converter.
  To do this, {prodname} provides the topic routing single message transformation (SMT). Configure this transformation in the {prodname} connector's Kafka Connect configuration. Configuration options enable you to specify the following:
  
  * An expression for identifying the records to re-route
  * An expression that resolves to the destination topic
  * How to ensure a unique key among the records being re-routed to the destination topic
  
  It is up to you to ensure that the transformation configuration provides the behavior that you want. {prodname} does not validate the behavior that results from your configuration of the transformation.
  
  The topic routing transformation is a
  link:https://kafka.apache.org/documentation/#connect_transforms[Kafka Connect SMT].
  
  ifdef::product[]
  The following topics provide details:
  
  * xref:use-case-for-routing-debezium-records-to-topics-that-you-specify[]
  * xref:example-of-routing-debezium-records-for-multiple-tables-to-one-topic[]
  