Cloud Spanner V1 Client - Class RoutingHint (2.1.0)

Reference documentation and code samples for the Cloud Spanner V1 Client class RoutingHint.

RoutingHint can be optionally added to location-aware Spanner requests. It gives the server hints that can be used to route the request to an appropriate server, potentially significantly decreasing latency and improving throughput. To achieve improved performance, most fields must be filled in with accurate values.

The presence of a valid RoutingHint tells the server that the client is location-aware. RoutingHint does not change the semantics of the request; it is purely a performance hint; the request will perform the same actions on the database's data as if RoutingHint were not present. However, if the RoutingHint is incomplete or incorrect, the response may include a CacheUpdate the client can use to correct its location cache.

Generated from protobuf message google.spanner.v1.RoutingHint

Constructor.

A session-scoped unique ID for the operation, computed client-side.

Requests with the same operation_uid should have a shared 'shape', meaning that some fields are expected to be the same, such as the SQL query, the target table/columns (for reads) etc. Requests with the same operation_uid are meant to differ only in fields like keys/key ranges/query parameters, transaction IDs, etc. operation_uid must be non-zero for RoutingHint to be valid.

A session-scoped unique ID for the operation, computed client-side.

Requests with the same operation_uid should have a shared 'shape', meaning that some fields are expected to be the same, such as the SQL query, the target table/columns (for reads) etc. Requests with the same operation_uid are meant to differ only in fields like keys/key ranges/query parameters, transaction IDs, etc. operation_uid must be non-zero for RoutingHint to be valid.

The database ID of the database being accessed, see CacheUpdate.database_id . Should match the cache entries that were used to generate the rest of the fields in this RoutingHint .

The database ID of the database being accessed, see CacheUpdate.database_id . Should match the cache entries that were used to generate the rest of the fields in this RoutingHint .

The schema generation of the recipe that was used to generate key and limit_key . See also RecipeList.schema_generation .

The schema generation of the recipe that was used to generate key and limit_key . See also RecipeList.schema_generation .

The key / key range that this request accesses. For operations that access a single key, key should be set and limit_key should be empty.

For operations that access a key range, key and limit_key should both be set, to the inclusive start and exclusive end of the range respectively. The keys are encoded in "sortable string format" (ssformat), using a KeyRecipe that is appropriate for the request. See KeyRecipe for more details.

The key / key range that this request accesses. For operations that access a single key, key should be set and limit_key should be empty.

For operations that access a key range, key and limit_key should both be set, to the inclusive start and exclusive end of the range respectively. The keys are encoded in "sortable string format" (ssformat), using a KeyRecipe that is appropriate for the request. See KeyRecipe for more details.

If this request targets a key range, this is the exclusive end of the range. See key for more details.

If this request targets a key range, this is the exclusive end of the range. See key for more details.

The group UID of the group that the client believes serves the range defined by key and limit_key . See Range.group_uid for more details.

The group UID of the group that the client believes serves the range defined by key and limit_key . See Range.group_uid for more details.

The split ID of the split that the client believes contains the range defined by key and limit_key . See Range.split_id for more details.

The split ID of the split that the client believes contains the range defined by key and limit_key . See Range.split_id for more details.

The tablet UID of the tablet from group group_uid that the client believes is best to serve this request. See Group.local_tablet_uids and Group.leader_tablet_uid .

The tablet UID of the tablet from group group_uid that the client believes is best to serve this request. See Group.local_tablet_uids and Group.leader_tablet_uid .

If the client had multiple options for tablet selection, and some of its first choices were unhealthy (e.g., the server is unreachable, or Tablet.skip is true), this field will contain the tablet UIDs of those tablets, with their incarnations. The server may include a CacheUpdate with new locations for those tablets.

If the client had multiple options for tablet selection, and some of its first choices were unhealthy (e.g., the server is unreachable, or Tablet.skip is true), this field will contain the tablet UIDs of those tablets, with their incarnations. The server may include a CacheUpdate with new locations for those tablets.

If present, the client's current location. In the Spanner managed service, this should be the name of a Google Cloud zone or region, such as "us-central1". In Spanner Omni, this should correspond to a previously created location.

If absent, the client's location will be assumed to be the same as the location of the server the client ends up connected to. Locations are primarily valuable for clients that connect from regions other than the ones that contain the Spanner database.

If present, the client's current location. In the Spanner managed service, this should be the name of a Google Cloud zone or region, such as "us-central1". In Spanner Omni, this should correspond to a previously created location.

If absent, the client's location will be assumed to be the same as the location of the server the client ends up connected to. Locations are primarily valuable for clients that connect from regions other than the ones that contain the Spanner database.