Class AppProfile.MultiClusterRoutingUseAny.RowAffinity.Builder

java.lang.Object
com.google.protobuf.AbstractMessageLite.Builder
com.google.protobuf.AbstractMessage.Builder<BuilderT>
com.google.protobuf.GeneratedMessageV3.Builder<AppProfile.MultiClusterRoutingUseAny.RowAffinity.Builder>
com.google.bigtable.admin.v2.AppProfile.MultiClusterRoutingUseAny.RowAffinity.Builder
All Implemented Interfaces:
AppProfile.MultiClusterRoutingUseAny.RowAffinityOrBuilder, com.google.protobuf.Message.Builder, com.google.protobuf.MessageLite.Builder, com.google.protobuf.MessageLiteOrBuilder, com.google.protobuf.MessageOrBuilder, Cloneable
Enclosing class:
AppProfile.MultiClusterRoutingUseAny.RowAffinity

public static final class AppProfile.MultiClusterRoutingUseAny.RowAffinity.Builder extends com.google.protobuf.GeneratedMessageV3.Builder<AppProfile.MultiClusterRoutingUseAny.RowAffinity.Builder> implements AppProfile.MultiClusterRoutingUseAny.RowAffinityOrBuilder
 If enabled, Bigtable will route the request based on the row key of the
 request, rather than randomly. Instead, each row key will be assigned
 to a cluster, and will stick to that cluster. If clusters are added or
 removed, then this may affect which row keys stick to which clusters.
 To avoid this, users can use a cluster group to specify which clusters
 are to be used. In this case, new clusters that are not a part of the
 cluster group will not be routed to, and routing will be unaffected by
 the new cluster. Moreover, clusters specified in the cluster group cannot
 be deleted unless removed from the cluster group.
 
Protobuf type google.bigtable.admin.v2.AppProfile.MultiClusterRoutingUseAny.RowAffinity