eab148 commented on code in PR #6484:
URL: https://github.com/apache/hbase/pull/6484#discussion_r1857123374
##########
hbase-client/src/main/java/org/apache/hadoop/hbase/replication/ReplicationPeerConfigBuilder.java:
##########
@@ -97,13 +97,39 @@ default ReplicationPeerConfigBuilder
putAllPeerData(Map<byte[], byte[]> peerData
*/
ReplicationPeerConfigBuilder setTableCFsMap(Map<TableName, List<String>>
tableCFsMap);
+ /**
+ * Sets an explicit map of source to sink tables that should be replicated
to the given peer. If
+ * the map is empty for a table, the source table is used for the given peer.
+ * @param sourceToSinkTableOverrides A map from a source tableName to sink
tableName. By default,
+ * edits will be replicated to the same
target table as the
+ * source table. A null or empty
collection can be passed to
+ * indicate there are no overrides.
+ * @return {@code this}
+ */
+ ReplicationPeerConfigBuilder
+ setSourceToSinkTableOverrides(Map<TableName, TableName>
sourceToSinkTableOverrides);
Review Comment:
My original motivation for having namespace and tableName scoped overrides
was two fold.
> 1. Every imaginable naming override can be categorized into one of these
two buckets. Say, for example, we want to support column family name
translations in the future. We’d need to provide a family → sinkFamily map for
the given tableName because multiple tableNames could have the same column
family name. On the other hand, say we want to add a prefix to all tables in
the namespace N. We’d need to add a prefix for a given namespace.
>
> 2. This framework follows the existing architecture for replication.
Currently, in the ReplicationPeerConfig, clients can opt namespaces or
(tableName, family) pairs into or out of replication. Thus, it makes sense to
allow users to opt namespaces or tableNames into naming overrides for
replication.
This is copied from the design doc, which I did not link before you reviewed
the PR (apologies for that)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
