google-apis-spanner_v1 0.18.0 → 0.22.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 65f291bc4c13a877c513f8b6ac04a3649db401654adb0e09ae58552151b3014a
-  data.tar.gz: 25d78f30d9b22e2d035ee29638ed7e896cddc89b531af81f5422a336d0c5c720
+  metadata.gz: ed2d0f9e6501204d162396c8339cefc663a38cede35c0ed2b766c7994103a0b5
+  data.tar.gz: b014d9c65ff06d2ac0211d07ac0e6f9359a799efa669c1707620f26ed3d9d9e9
 SHA512:
-  metadata.gz: 69c490c9ee531e44481798c6f97a81063bfae060b3b30dcc42271f6f96ac364bc7dc03896145d4d9c1e51bcbc8da81be87cabc048911ec76d188b08d2e1f713b
-  data.tar.gz: 780daa7897e74b6d85e3a09a2c148c73f3241a620be09ee254331bdaf04fac84fe6f7c8f47a85149518ef811e62f72d76364a3955071f961cadb6e646fa3f108
+  metadata.gz: 7ee74bf1e5291c6ae6ef08c45fb93a4ad18db66cafcaa009cbe1c2ed79e97ee188ac94bbcb9aa9e6cbcbc65c9dd2badbb022fa889e6028f3f984f6513b54f31b
+  data.tar.gz: 55b4f765118c3e147cb569ea34ff2d2c2f4855eef8dc456b2846242e3f23f315f03c1dbd5ea823cb4da7cd5b755f924ddb192d40b204bbd64afe6010e9b4eb2e

data/CHANGELOG.md

@@ -1,5 +1,22 @@
 # Release history for google-apis-spanner_v1
 
+### v0.22.0 (2021-12-16)
+
+* Regenerated from discovery document revision 20211203
+
+### v0.21.0 (2021-12-05)
+
+* Regenerated from discovery document revision 20211202
+
+### v0.20.0 (2021-10-23)
+
+* Regenerated from discovery document revision 20211021
+* Unspecified changes
+
+### v0.19.0 (2021-09-27)
+
+* Regenerated from discovery document revision 20210914
+
 ### v0.18.0 (2021-08-30)
 
 * Regenerated from discovery document revision 20210825

data/OVERVIEW.md

@@ -51,7 +51,7 @@ require "google/apis/spanner_v1"
 client = Google::Apis::SpannerV1::SpannerService.new
 
 # Authenticate calls
-client.authentication = # ... use the googleauth gem to create credentials
+client.authorization = # ... use the googleauth gem to create credentials
 ```
 
 See the class reference docs for information on the methods you can call from a client.
@@ -60,8 +60,8 @@ See the class reference docs for information on the methods you can call from a
 
 More detailed descriptions of the Google simple REST clients are available in two documents.
 
- *  The [Usage Guide](https://github.com/googleapis/google-api-ruby-client/blob/master/docs/usage-guide.md) discusses how to make API calls, how to use the provided data structures, and how to work the various features of the client library, including media upload and download, error handling, retries, pagination, and logging.
- *  The [Auth Guide](https://github.com/googleapis/google-api-ruby-client/blob/master/docs/auth-guide.md) discusses authentication in the client libraries, including API keys, OAuth 2.0, service accounts, and environment variables.
+ *  The [Usage Guide](https://github.com/googleapis/google-api-ruby-client/blob/main/docs/usage-guide.md) discusses how to make API calls, how to use the provided data structures, and how to work the various features of the client library, including media upload and download, error handling, retries, pagination, and logging.
+ *  The [Auth Guide](https://github.com/googleapis/google-api-ruby-client/blob/main/docs/auth-guide.md) discusses authentication in the client libraries, including API keys, OAuth 2.0, service accounts, and environment variables.
 
 (Note: the above documents are written for the simple REST clients in general, and their examples may not reflect the Spanner service in particular.)
 

data/lib/google/apis/spanner_v1/classes.rb

@@ -248,49 +248,50 @@ module Google
         # committing the retry, the client should execute the retry in the same session
         # as the original attempt. The original session's lock priority increases with
         # each consecutive abort, meaning that each attempt has a slightly better chance
-        # of success than the previous. Under some circumstances (e.g., many
+        # of success than the previous. Under some circumstances (for example, many
         # transactions attempting to modify the same row(s)), a transaction can abort
         # many times in a short period before successfully committing. Thus, it is not a
         # good idea to cap the number of retries a transaction can attempt; instead, it
-        # is better to limit the total amount of wall time spent retrying. Idle
-        # Transactions: A transaction is considered idle if it has no outstanding reads
-        # or SQL queries and has not started a read or SQL query within the last 10
-        # seconds. Idle transactions can be aborted by Cloud Spanner so that they don't
-        # hold on to locks indefinitely. In that case, the commit will fail with error `
-        # ABORTED`. If this behavior is undesirable, periodically executing a simple SQL
-        # query in the transaction (e.g., `SELECT 1`) prevents the transaction from
-        # becoming idle. Snapshot Read-Only Transactions: Snapshot read-only
-        # transactions provides a simpler method than locking read-write transactions
-        # for doing several consistent reads. However, this type of transaction does not
-        # support writes. Snapshot transactions do not take locks. Instead, they work by
-        # choosing a Cloud Spanner timestamp, then executing all reads at that timestamp.
-        # Since they do not acquire locks, they do not block concurrent read-write
-        # transactions. Unlike locking read-write transactions, snapshot read-only
-        # transactions never abort. They can fail if the chosen read timestamp is
-        # garbage collected; however, the default garbage collection policy is generous
-        # enough that most applications do not need to worry about this in practice.
-        # Snapshot read-only transactions do not need to call Commit or Rollback (and in
-        # fact are not permitted to do so). To execute a snapshot transaction, the
-        # client specifies a timestamp bound, which tells Cloud Spanner how to choose a
-        # read timestamp. The types of timestamp bound are: - Strong (the default). -
-        # Bounded staleness. - Exact staleness. If the Cloud Spanner database to be read
-        # is geographically distributed, stale read-only transactions can execute more
-        # quickly than strong or read-write transaction, because they are able to
-        # execute far from the leader replica. Each type of timestamp bound is discussed
-        # in detail below. Strong: Strong reads are guaranteed to see the effects of all
-        # transactions that have committed before the start of the read. Furthermore,
-        # all rows yielded by a single read are consistent with each other -- if any
-        # part of the read observes a transaction, all parts of the read see the
-        # transaction. Strong reads are not repeatable: two consecutive strong read-only
-        # transactions might return inconsistent results if there are concurrent writes.
-        # If consistency across reads is required, the reads should be executed within a
-        # transaction or at an exact read timestamp. See TransactionOptions.ReadOnly.
-        # strong. Exact Staleness: These timestamp bounds execute reads at a user-
-        # specified timestamp. Reads at a timestamp are guaranteed to see a consistent
-        # prefix of the global transaction history: they observe modifications done by
-        # all transactions with a commit timestamp <= the read timestamp, and observe
-        # none of the modifications done by transactions with a larger commit timestamp.
-        # They will block until all conflicting transactions that may be assigned commit
+        # is better to limit the total amount of time spent retrying. Idle Transactions:
+        # A transaction is considered idle if it has no outstanding reads or SQL queries
+        # and has not started a read or SQL query within the last 10 seconds. Idle
+        # transactions can be aborted by Cloud Spanner so that they don't hold on to
+        # locks indefinitely. If an idle transaction is aborted, the commit will fail
+        # with error `ABORTED`. If this behavior is undesirable, periodically executing
+        # a simple SQL query in the transaction (for example, `SELECT 1`) prevents the
+        # transaction from becoming idle. Snapshot Read-Only Transactions: Snapshot read-
+        # only transactions provides a simpler method than locking read-write
+        # transactions for doing several consistent reads. However, this type of
+        # transaction does not support writes. Snapshot transactions do not take locks.
+        # Instead, they work by choosing a Cloud Spanner timestamp, then executing all
+        # reads at that timestamp. Since they do not acquire locks, they do not block
+        # concurrent read-write transactions. Unlike locking read-write transactions,
+        # snapshot read-only transactions never abort. They can fail if the chosen read
+        # timestamp is garbage collected; however, the default garbage collection policy
+        # is generous enough that most applications do not need to worry about this in
+        # practice. Snapshot read-only transactions do not need to call Commit or
+        # Rollback (and in fact are not permitted to do so). To execute a snapshot
+        # transaction, the client specifies a timestamp bound, which tells Cloud Spanner
+        # how to choose a read timestamp. The types of timestamp bound are: - Strong (
+        # the default). - Bounded staleness. - Exact staleness. If the Cloud Spanner
+        # database to be read is geographically distributed, stale read-only
+        # transactions can execute more quickly than strong or read-write transaction,
+        # because they are able to execute far from the leader replica. Each type of
+        # timestamp bound is discussed in detail below. Strong: Strong reads are
+        # guaranteed to see the effects of all transactions that have committed before
+        # the start of the read. Furthermore, all rows yielded by a single read are
+        # consistent with each other -- if any part of the read observes a transaction,
+        # all parts of the read see the transaction. Strong reads are not repeatable:
+        # two consecutive strong read-only transactions might return inconsistent
+        # results if there are concurrent writes. If consistency across reads is
+        # required, the reads should be executed within a transaction or at an exact
+        # read timestamp. See TransactionOptions.ReadOnly.strong. Exact Staleness: These
+        # timestamp bounds execute reads at a user-specified timestamp. Reads at a
+        # timestamp are guaranteed to see a consistent prefix of the global transaction
+        # history: they observe modifications done by all transactions with a commit
+        # timestamp less than or equal to the read timestamp, and observe none of the
+        # modifications done by transactions with a larger commit timestamp. They will
+        # block until all conflicting transactions that may be assigned commit
         # timestamps <= the read timestamp have finished. The timestamp can either be
         # expressed as an absolute Cloud Spanner commit timestamp or a staleness
         # relative to the current time. These modes do not require a "negotiation phase"
@@ -380,7 +381,7 @@ module Google
         end
       end
       
-      # Associates `members` with a `role`.
+      # Associates `members`, or principals, with a `role`.
       class Binding
         include Google::Apis::Core::Hashable
       
@@ -403,7 +404,7 @@ module Google
         # @return [Google::Apis::SpannerV1::Expr]
         attr_accessor :condition
       
-        # Specifies the identities requesting access for a Cloud Platform resource. `
+        # Specifies the principals requesting access for a Cloud Platform resource. `
         # members` can have the following values: * `allUsers`: A special identifier
         # that represents anyone who is on the internet; with or without a Google
         # account. * `allAuthenticatedUsers`: A special identifier that represents
@@ -433,8 +434,8 @@ module Google
         # @return [Array<String>]
         attr_accessor :members
       
-        # Role that is assigned to `members`. For example, `roles/viewer`, `roles/editor`
-        # , or `roles/owner`.
+        # Role that is assigned to the list of `members`, or principals. For example, `
+        # roles/viewer`, `roles/editor`, or `roles/owner`.
         # Corresponds to the JSON property `role`
         # @return [String]
         attr_accessor :role
@@ -559,49 +560,50 @@ module Google
         # committing the retry, the client should execute the retry in the same session
         # as the original attempt. The original session's lock priority increases with
         # each consecutive abort, meaning that each attempt has a slightly better chance
-        # of success than the previous. Under some circumstances (e.g., many
+        # of success than the previous. Under some circumstances (for example, many
         # transactions attempting to modify the same row(s)), a transaction can abort
         # many times in a short period before successfully committing. Thus, it is not a
         # good idea to cap the number of retries a transaction can attempt; instead, it
-        # is better to limit the total amount of wall time spent retrying. Idle
-        # Transactions: A transaction is considered idle if it has no outstanding reads
-        # or SQL queries and has not started a read or SQL query within the last 10
-        # seconds. Idle transactions can be aborted by Cloud Spanner so that they don't
-        # hold on to locks indefinitely. In that case, the commit will fail with error `
-        # ABORTED`. If this behavior is undesirable, periodically executing a simple SQL
-        # query in the transaction (e.g., `SELECT 1`) prevents the transaction from
-        # becoming idle. Snapshot Read-Only Transactions: Snapshot read-only
-        # transactions provides a simpler method than locking read-write transactions
-        # for doing several consistent reads. However, this type of transaction does not
-        # support writes. Snapshot transactions do not take locks. Instead, they work by
-        # choosing a Cloud Spanner timestamp, then executing all reads at that timestamp.
-        # Since they do not acquire locks, they do not block concurrent read-write
-        # transactions. Unlike locking read-write transactions, snapshot read-only
-        # transactions never abort. They can fail if the chosen read timestamp is
-        # garbage collected; however, the default garbage collection policy is generous
-        # enough that most applications do not need to worry about this in practice.
-        # Snapshot read-only transactions do not need to call Commit or Rollback (and in
-        # fact are not permitted to do so). To execute a snapshot transaction, the
-        # client specifies a timestamp bound, which tells Cloud Spanner how to choose a
-        # read timestamp. The types of timestamp bound are: - Strong (the default). -
-        # Bounded staleness. - Exact staleness. If the Cloud Spanner database to be read
-        # is geographically distributed, stale read-only transactions can execute more
-        # quickly than strong or read-write transaction, because they are able to
-        # execute far from the leader replica. Each type of timestamp bound is discussed
-        # in detail below. Strong: Strong reads are guaranteed to see the effects of all
-        # transactions that have committed before the start of the read. Furthermore,
-        # all rows yielded by a single read are consistent with each other -- if any
-        # part of the read observes a transaction, all parts of the read see the
-        # transaction. Strong reads are not repeatable: two consecutive strong read-only
-        # transactions might return inconsistent results if there are concurrent writes.
-        # If consistency across reads is required, the reads should be executed within a
-        # transaction or at an exact read timestamp. See TransactionOptions.ReadOnly.
-        # strong. Exact Staleness: These timestamp bounds execute reads at a user-
-        # specified timestamp. Reads at a timestamp are guaranteed to see a consistent
-        # prefix of the global transaction history: they observe modifications done by
-        # all transactions with a commit timestamp <= the read timestamp, and observe
-        # none of the modifications done by transactions with a larger commit timestamp.
-        # They will block until all conflicting transactions that may be assigned commit
+        # is better to limit the total amount of time spent retrying. Idle Transactions:
+        # A transaction is considered idle if it has no outstanding reads or SQL queries
+        # and has not started a read or SQL query within the last 10 seconds. Idle
+        # transactions can be aborted by Cloud Spanner so that they don't hold on to
+        # locks indefinitely. If an idle transaction is aborted, the commit will fail
+        # with error `ABORTED`. If this behavior is undesirable, periodically executing
+        # a simple SQL query in the transaction (for example, `SELECT 1`) prevents the
+        # transaction from becoming idle. Snapshot Read-Only Transactions: Snapshot read-
+        # only transactions provides a simpler method than locking read-write
+        # transactions for doing several consistent reads. However, this type of
+        # transaction does not support writes. Snapshot transactions do not take locks.
+        # Instead, they work by choosing a Cloud Spanner timestamp, then executing all
+        # reads at that timestamp. Since they do not acquire locks, they do not block
+        # concurrent read-write transactions. Unlike locking read-write transactions,
+        # snapshot read-only transactions never abort. They can fail if the chosen read
+        # timestamp is garbage collected; however, the default garbage collection policy
+        # is generous enough that most applications do not need to worry about this in
+        # practice. Snapshot read-only transactions do not need to call Commit or
+        # Rollback (and in fact are not permitted to do so). To execute a snapshot
+        # transaction, the client specifies a timestamp bound, which tells Cloud Spanner
+        # how to choose a read timestamp. The types of timestamp bound are: - Strong (
+        # the default). - Bounded staleness. - Exact staleness. If the Cloud Spanner
+        # database to be read is geographically distributed, stale read-only
+        # transactions can execute more quickly than strong or read-write transaction,
+        # because they are able to execute far from the leader replica. Each type of
+        # timestamp bound is discussed in detail below. Strong: Strong reads are
+        # guaranteed to see the effects of all transactions that have committed before
+        # the start of the read. Furthermore, all rows yielded by a single read are
+        # consistent with each other -- if any part of the read observes a transaction,
+        # all parts of the read see the transaction. Strong reads are not repeatable:
+        # two consecutive strong read-only transactions might return inconsistent
+        # results if there are concurrent writes. If consistency across reads is
+        # required, the reads should be executed within a transaction or at an exact
+        # read timestamp. See TransactionOptions.ReadOnly.strong. Exact Staleness: These
+        # timestamp bounds execute reads at a user-specified timestamp. Reads at a
+        # timestamp are guaranteed to see a consistent prefix of the global transaction
+        # history: they observe modifications done by all transactions with a commit
+        # timestamp less than or equal to the read timestamp, and observe none of the
+        # modifications done by transactions with a larger commit timestamp. They will
+        # block until all conflicting transactions that may be assigned commit
         # timestamps <= the read timestamp have finished. The timestamp can either be
         # expressed as an absolute Cloud Spanner commit timestamp or a staleness
         # relative to the current time. These modes do not require a "negotiation phase"
@@ -1560,13 +1562,16 @@ module Google
       class GetPolicyOptions
         include Google::Apis::Core::Hashable
       
-        # Optional. The policy format version to be returned. Valid values are 0, 1, and
-        # 3. Requests specifying an invalid value will be rejected. Requests for
-        # policies with any conditional bindings must specify version 3. Policies
-        # without any conditional bindings may specify any valid value or leave the
-        # field unset. To learn which resources support conditions in their IAM policies,
-        # see the [IAM documentation](https://cloud.google.com/iam/help/conditions/
-        # resource-policies).
+        # Optional. The maximum policy version that will be used to format the policy.
+        # Valid values are 0, 1, and 3. Requests specifying an invalid value will be
+        # rejected. Requests for policies with any conditional role bindings must
+        # specify version 3. Policies with no conditional role bindings may specify any
+        # valid value or leave the field unset. The policy in the response might use the
+        # policy version that you specified, or it might use a lower policy version. For
+        # example, if you specify version 3, but the policy has no conditional role
+        # bindings, the response uses version 1. To learn which resources support
+        # conditions in their IAM policies, see the [IAM documentation](https://cloud.
+        # google.com/iam/help/conditions/resource-policies).
         # Corresponds to the JSON property `requestedPolicyVersion`
         # @return [Fixnum]
         attr_accessor :requested_policy_version
@@ -1725,7 +1730,7 @@ module Google
         # @return [String]
         attr_accessor :display_name
       
-        # Allowed values of the “default_leader” schema option for databases in
+        # Allowed values of the "default_leader" schema option for databases in
         # instances that use this instance configuration.
         # Corresponds to the JSON property `leaderOptions`
         # @return [Array<String>]
@@ -2915,37 +2920,42 @@ module Google
       
       # An Identity and Access Management (IAM) policy, which specifies access
       # controls for Google Cloud resources. A `Policy` is a collection of `bindings`.
-      # A `binding` binds one or more `members` to a single `role`. Members can be
-      # user accounts, service accounts, Google groups, and domains (such as G Suite).
-      # A `role` is a named list of permissions; each `role` can be an IAM predefined
-      # role or a user-created custom role. For some types of Google Cloud resources,
-      # a `binding` can also specify a `condition`, which is a logical expression that
-      # allows access to a resource only if the expression evaluates to `true`. A
-      # condition can add constraints based on attributes of the request, the resource,
-      # or both. To learn which resources support conditions in their IAM policies,
-      # see the [IAM documentation](https://cloud.google.com/iam/help/conditions/
-      # resource-policies). **JSON example:** ` "bindings": [ ` "role": "roles/
-      # resourcemanager.organizationAdmin", "members": [ "user:mike@example.com", "
-      # group:admins@example.com", "domain:google.com", "serviceAccount:my-project-id@
-      # appspot.gserviceaccount.com" ] `, ` "role": "roles/resourcemanager.
-      # organizationViewer", "members": [ "user:eve@example.com" ], "condition": ` "
-      # title": "expirable access", "description": "Does not grant access after Sep
-      # 2020", "expression": "request.time < timestamp('2020-10-01T00:00:00.000Z')", `
-      # ` ], "etag": "BwWWja0YfJA=", "version": 3 ` **YAML example:** bindings: -
-      # members: - user:mike@example.com - group:admins@example.com - domain:google.
-      # com - serviceAccount:my-project-id@appspot.gserviceaccount.com role: roles/
-      # resourcemanager.organizationAdmin - members: - user:eve@example.com role:
-      # roles/resourcemanager.organizationViewer condition: title: expirable access
-      # description: Does not grant access after Sep 2020 expression: request.time <
-      # timestamp('2020-10-01T00:00:00.000Z') etag: BwWWja0YfJA= version: 3 For a
-      # description of IAM and its features, see the [IAM documentation](https://cloud.
-      # google.com/iam/docs/).
+      # A `binding` binds one or more `members`, or principals, to a single `role`.
+      # Principals can be user accounts, service accounts, Google groups, and domains (
+      # such as G Suite). A `role` is a named list of permissions; each `role` can be
+      # an IAM predefined role or a user-created custom role. For some types of Google
+      # Cloud resources, a `binding` can also specify a `condition`, which is a
+      # logical expression that allows access to a resource only if the expression
+      # evaluates to `true`. A condition can add constraints based on attributes of
+      # the request, the resource, or both. To learn which resources support
+      # conditions in their IAM policies, see the [IAM documentation](https://cloud.
+      # google.com/iam/help/conditions/resource-policies). **JSON example:** ` "
+      # bindings": [ ` "role": "roles/resourcemanager.organizationAdmin", "members": [
+      # "user:mike@example.com", "group:admins@example.com", "domain:google.com", "
+      # serviceAccount:my-project-id@appspot.gserviceaccount.com" ] `, ` "role": "
+      # roles/resourcemanager.organizationViewer", "members": [ "user:eve@example.com"
+      # ], "condition": ` "title": "expirable access", "description": "Does not grant
+      # access after Sep 2020", "expression": "request.time < timestamp('2020-10-01T00:
+      # 00:00.000Z')", ` ` ], "etag": "BwWWja0YfJA=", "version": 3 ` **YAML example:**
+      # bindings: - members: - user:mike@example.com - group:admins@example.com -
+      # domain:google.com - serviceAccount:my-project-id@appspot.gserviceaccount.com
+      # role: roles/resourcemanager.organizationAdmin - members: - user:eve@example.
+      # com role: roles/resourcemanager.organizationViewer condition: title: expirable
+      # access description: Does not grant access after Sep 2020 expression: request.
+      # time < timestamp('2020-10-01T00:00:00.000Z') etag: BwWWja0YfJA= version: 3 For
+      # a description of IAM and its features, see the [IAM documentation](https://
+      # cloud.google.com/iam/docs/).
       class Policy
         include Google::Apis::Core::Hashable
       
-        # Associates a list of `members` to a `role`. Optionally, may specify a `
-        # condition` that determines how and when the `bindings` are applied. Each of
-        # the `bindings` must contain at least one member.
+        # Associates a list of `members`, or principals, with a `role`. Optionally, may
+        # specify a `condition` that determines how and when the `bindings` are applied.
+        # Each of the `bindings` must contain at least one principal. The `bindings` in
+        # a `Policy` can refer to up to 1,500 principals; up to 250 of these principals
+        # can be Google groups. Each occurrence of a principal counts towards these
+        # limits. For example, if the `bindings` grant 50 different roles to `user:alice@
+        # example.com`, and not to any other principal, then you can add another 1,450
+        # principals to the `bindings` in the `Policy`.
         # Corresponds to the JSON property `bindings`
         # @return [Array<Google::Apis::SpannerV1::Binding>]
         attr_accessor :bindings
@@ -3347,7 +3357,7 @@ module Google
         # A tag used for statistics collection about this transaction. Both request_tag
         # and transaction_tag can be specified for a read or query that belongs to a
         # transaction. The value of transaction_tag should be the same for all requests
-        # belonging to the same transaction. If this request doesn’t belong to any
+        # belonging to the same transaction. If this request doesn't belong to any
         # transaction, transaction_tag will be ignored. Legal characters for `
         # transaction_tag` values are all printable characters (ASCII 32 - 126) and the
         # length of a transaction_tag is limited to 50 characters. Values that exceed
@@ -3769,31 +3779,31 @@ module Google
       
         # An Identity and Access Management (IAM) policy, which specifies access
         # controls for Google Cloud resources. A `Policy` is a collection of `bindings`.
-        # A `binding` binds one or more `members` to a single `role`. Members can be
-        # user accounts, service accounts, Google groups, and domains (such as G Suite).
-        # A `role` is a named list of permissions; each `role` can be an IAM predefined
-        # role or a user-created custom role. For some types of Google Cloud resources,
-        # a `binding` can also specify a `condition`, which is a logical expression that
-        # allows access to a resource only if the expression evaluates to `true`. A
-        # condition can add constraints based on attributes of the request, the resource,
-        # or both. To learn which resources support conditions in their IAM policies,
-        # see the [IAM documentation](https://cloud.google.com/iam/help/conditions/
-        # resource-policies). **JSON example:** ` "bindings": [ ` "role": "roles/
-        # resourcemanager.organizationAdmin", "members": [ "user:mike@example.com", "
-        # group:admins@example.com", "domain:google.com", "serviceAccount:my-project-id@
-        # appspot.gserviceaccount.com" ] `, ` "role": "roles/resourcemanager.
-        # organizationViewer", "members": [ "user:eve@example.com" ], "condition": ` "
-        # title": "expirable access", "description": "Does not grant access after Sep
-        # 2020", "expression": "request.time < timestamp('2020-10-01T00:00:00.000Z')", `
-        # ` ], "etag": "BwWWja0YfJA=", "version": 3 ` **YAML example:** bindings: -
-        # members: - user:mike@example.com - group:admins@example.com - domain:google.
-        # com - serviceAccount:my-project-id@appspot.gserviceaccount.com role: roles/
-        # resourcemanager.organizationAdmin - members: - user:eve@example.com role:
-        # roles/resourcemanager.organizationViewer condition: title: expirable access
-        # description: Does not grant access after Sep 2020 expression: request.time <
-        # timestamp('2020-10-01T00:00:00.000Z') etag: BwWWja0YfJA= version: 3 For a
-        # description of IAM and its features, see the [IAM documentation](https://cloud.
-        # google.com/iam/docs/).
+        # A `binding` binds one or more `members`, or principals, to a single `role`.
+        # Principals can be user accounts, service accounts, Google groups, and domains (
+        # such as G Suite). A `role` is a named list of permissions; each `role` can be
+        # an IAM predefined role or a user-created custom role. For some types of Google
+        # Cloud resources, a `binding` can also specify a `condition`, which is a
+        # logical expression that allows access to a resource only if the expression
+        # evaluates to `true`. A condition can add constraints based on attributes of
+        # the request, the resource, or both. To learn which resources support
+        # conditions in their IAM policies, see the [IAM documentation](https://cloud.
+        # google.com/iam/help/conditions/resource-policies). **JSON example:** ` "
+        # bindings": [ ` "role": "roles/resourcemanager.organizationAdmin", "members": [
+        # "user:mike@example.com", "group:admins@example.com", "domain:google.com", "
+        # serviceAccount:my-project-id@appspot.gserviceaccount.com" ] `, ` "role": "
+        # roles/resourcemanager.organizationViewer", "members": [ "user:eve@example.com"
+        # ], "condition": ` "title": "expirable access", "description": "Does not grant
+        # access after Sep 2020", "expression": "request.time < timestamp('2020-10-01T00:
+        # 00:00.000Z')", ` ` ], "etag": "BwWWja0YfJA=", "version": 3 ` **YAML example:**
+        # bindings: - members: - user:mike@example.com - group:admins@example.com -
+        # domain:google.com - serviceAccount:my-project-id@appspot.gserviceaccount.com
+        # role: roles/resourcemanager.organizationAdmin - members: - user:eve@example.
+        # com role: roles/resourcemanager.organizationViewer condition: title: expirable
+        # access description: Does not grant access after Sep 2020 expression: request.
+        # time < timestamp('2020-10-01T00:00:00.000Z') etag: BwWWja0YfJA= version: 3 For
+        # a description of IAM and its features, see the [IAM documentation](https://
+        # cloud.google.com/iam/docs/).
         # Corresponds to the JSON property `policy`
         # @return [Google::Apis::SpannerV1::Policy]
         attr_accessor :policy
@@ -4057,49 +4067,50 @@ module Google
       # committing the retry, the client should execute the retry in the same session
       # as the original attempt. The original session's lock priority increases with
       # each consecutive abort, meaning that each attempt has a slightly better chance
-      # of success than the previous. Under some circumstances (e.g., many
+      # of success than the previous. Under some circumstances (for example, many
       # transactions attempting to modify the same row(s)), a transaction can abort
       # many times in a short period before successfully committing. Thus, it is not a
       # good idea to cap the number of retries a transaction can attempt; instead, it
-      # is better to limit the total amount of wall time spent retrying. Idle
-      # Transactions: A transaction is considered idle if it has no outstanding reads
-      # or SQL queries and has not started a read or SQL query within the last 10
-      # seconds. Idle transactions can be aborted by Cloud Spanner so that they don't
-      # hold on to locks indefinitely. In that case, the commit will fail with error `
-      # ABORTED`. If this behavior is undesirable, periodically executing a simple SQL
-      # query in the transaction (e.g., `SELECT 1`) prevents the transaction from
-      # becoming idle. Snapshot Read-Only Transactions: Snapshot read-only
-      # transactions provides a simpler method than locking read-write transactions
-      # for doing several consistent reads. However, this type of transaction does not
-      # support writes. Snapshot transactions do not take locks. Instead, they work by
-      # choosing a Cloud Spanner timestamp, then executing all reads at that timestamp.
-      # Since they do not acquire locks, they do not block concurrent read-write
-      # transactions. Unlike locking read-write transactions, snapshot read-only
-      # transactions never abort. They can fail if the chosen read timestamp is
-      # garbage collected; however, the default garbage collection policy is generous
-      # enough that most applications do not need to worry about this in practice.
-      # Snapshot read-only transactions do not need to call Commit or Rollback (and in
-      # fact are not permitted to do so). To execute a snapshot transaction, the
-      # client specifies a timestamp bound, which tells Cloud Spanner how to choose a
-      # read timestamp. The types of timestamp bound are: - Strong (the default). -
-      # Bounded staleness. - Exact staleness. If the Cloud Spanner database to be read
-      # is geographically distributed, stale read-only transactions can execute more
-      # quickly than strong or read-write transaction, because they are able to
-      # execute far from the leader replica. Each type of timestamp bound is discussed
-      # in detail below. Strong: Strong reads are guaranteed to see the effects of all
-      # transactions that have committed before the start of the read. Furthermore,
-      # all rows yielded by a single read are consistent with each other -- if any
-      # part of the read observes a transaction, all parts of the read see the
-      # transaction. Strong reads are not repeatable: two consecutive strong read-only
-      # transactions might return inconsistent results if there are concurrent writes.
-      # If consistency across reads is required, the reads should be executed within a
-      # transaction or at an exact read timestamp. See TransactionOptions.ReadOnly.
-      # strong. Exact Staleness: These timestamp bounds execute reads at a user-
-      # specified timestamp. Reads at a timestamp are guaranteed to see a consistent
-      # prefix of the global transaction history: they observe modifications done by
-      # all transactions with a commit timestamp <= the read timestamp, and observe
-      # none of the modifications done by transactions with a larger commit timestamp.
-      # They will block until all conflicting transactions that may be assigned commit
+      # is better to limit the total amount of time spent retrying. Idle Transactions:
+      # A transaction is considered idle if it has no outstanding reads or SQL queries
+      # and has not started a read or SQL query within the last 10 seconds. Idle
+      # transactions can be aborted by Cloud Spanner so that they don't hold on to
+      # locks indefinitely. If an idle transaction is aborted, the commit will fail
+      # with error `ABORTED`. If this behavior is undesirable, periodically executing
+      # a simple SQL query in the transaction (for example, `SELECT 1`) prevents the
+      # transaction from becoming idle. Snapshot Read-Only Transactions: Snapshot read-
+      # only transactions provides a simpler method than locking read-write
+      # transactions for doing several consistent reads. However, this type of
+      # transaction does not support writes. Snapshot transactions do not take locks.
+      # Instead, they work by choosing a Cloud Spanner timestamp, then executing all
+      # reads at that timestamp. Since they do not acquire locks, they do not block
+      # concurrent read-write transactions. Unlike locking read-write transactions,
+      # snapshot read-only transactions never abort. They can fail if the chosen read
+      # timestamp is garbage collected; however, the default garbage collection policy
+      # is generous enough that most applications do not need to worry about this in
+      # practice. Snapshot read-only transactions do not need to call Commit or
+      # Rollback (and in fact are not permitted to do so). To execute a snapshot
+      # transaction, the client specifies a timestamp bound, which tells Cloud Spanner
+      # how to choose a read timestamp. The types of timestamp bound are: - Strong (
+      # the default). - Bounded staleness. - Exact staleness. If the Cloud Spanner
+      # database to be read is geographically distributed, stale read-only
+      # transactions can execute more quickly than strong or read-write transaction,
+      # because they are able to execute far from the leader replica. Each type of
+      # timestamp bound is discussed in detail below. Strong: Strong reads are
+      # guaranteed to see the effects of all transactions that have committed before
+      # the start of the read. Furthermore, all rows yielded by a single read are
+      # consistent with each other -- if any part of the read observes a transaction,
+      # all parts of the read see the transaction. Strong reads are not repeatable:
+      # two consecutive strong read-only transactions might return inconsistent
+      # results if there are concurrent writes. If consistency across reads is
+      # required, the reads should be executed within a transaction or at an exact
+      # read timestamp. See TransactionOptions.ReadOnly.strong. Exact Staleness: These
+      # timestamp bounds execute reads at a user-specified timestamp. Reads at a
+      # timestamp are guaranteed to see a consistent prefix of the global transaction
+      # history: they observe modifications done by all transactions with a commit
+      # timestamp less than or equal to the read timestamp, and observe none of the
+      # modifications done by transactions with a larger commit timestamp. They will
+      # block until all conflicting transactions that may be assigned commit
       # timestamps <= the read timestamp have finished. The timestamp can either be
       # expressed as an absolute Cloud Spanner commit timestamp or a staleness
       # relative to the current time. These modes do not require a "negotiation phase"
@@ -4252,49 +4263,50 @@ module Google
         # committing the retry, the client should execute the retry in the same session
         # as the original attempt. The original session's lock priority increases with
         # each consecutive abort, meaning that each attempt has a slightly better chance
-        # of success than the previous. Under some circumstances (e.g., many
+        # of success than the previous. Under some circumstances (for example, many
         # transactions attempting to modify the same row(s)), a transaction can abort
         # many times in a short period before successfully committing. Thus, it is not a
         # good idea to cap the number of retries a transaction can attempt; instead, it
-        # is better to limit the total amount of wall time spent retrying. Idle
-        # Transactions: A transaction is considered idle if it has no outstanding reads
-        # or SQL queries and has not started a read or SQL query within the last 10
-        # seconds. Idle transactions can be aborted by Cloud Spanner so that they don't
-        # hold on to locks indefinitely. In that case, the commit will fail with error `
-        # ABORTED`. If this behavior is undesirable, periodically executing a simple SQL
-        # query in the transaction (e.g., `SELECT 1`) prevents the transaction from
-        # becoming idle. Snapshot Read-Only Transactions: Snapshot read-only
-        # transactions provides a simpler method than locking read-write transactions
-        # for doing several consistent reads. However, this type of transaction does not
-        # support writes. Snapshot transactions do not take locks. Instead, they work by
-        # choosing a Cloud Spanner timestamp, then executing all reads at that timestamp.
-        # Since they do not acquire locks, they do not block concurrent read-write
-        # transactions. Unlike locking read-write transactions, snapshot read-only
-        # transactions never abort. They can fail if the chosen read timestamp is
-        # garbage collected; however, the default garbage collection policy is generous
-        # enough that most applications do not need to worry about this in practice.
-        # Snapshot read-only transactions do not need to call Commit or Rollback (and in
-        # fact are not permitted to do so). To execute a snapshot transaction, the
-        # client specifies a timestamp bound, which tells Cloud Spanner how to choose a
-        # read timestamp. The types of timestamp bound are: - Strong (the default). -
-        # Bounded staleness. - Exact staleness. If the Cloud Spanner database to be read
-        # is geographically distributed, stale read-only transactions can execute more
-        # quickly than strong or read-write transaction, because they are able to
-        # execute far from the leader replica. Each type of timestamp bound is discussed
-        # in detail below. Strong: Strong reads are guaranteed to see the effects of all
-        # transactions that have committed before the start of the read. Furthermore,
-        # all rows yielded by a single read are consistent with each other -- if any
-        # part of the read observes a transaction, all parts of the read see the
-        # transaction. Strong reads are not repeatable: two consecutive strong read-only
-        # transactions might return inconsistent results if there are concurrent writes.
-        # If consistency across reads is required, the reads should be executed within a
-        # transaction or at an exact read timestamp. See TransactionOptions.ReadOnly.
-        # strong. Exact Staleness: These timestamp bounds execute reads at a user-
-        # specified timestamp. Reads at a timestamp are guaranteed to see a consistent
-        # prefix of the global transaction history: they observe modifications done by
-        # all transactions with a commit timestamp <= the read timestamp, and observe
-        # none of the modifications done by transactions with a larger commit timestamp.
-        # They will block until all conflicting transactions that may be assigned commit
+        # is better to limit the total amount of time spent retrying. Idle Transactions:
+        # A transaction is considered idle if it has no outstanding reads or SQL queries
+        # and has not started a read or SQL query within the last 10 seconds. Idle
+        # transactions can be aborted by Cloud Spanner so that they don't hold on to
+        # locks indefinitely. If an idle transaction is aborted, the commit will fail
+        # with error `ABORTED`. If this behavior is undesirable, periodically executing
+        # a simple SQL query in the transaction (for example, `SELECT 1`) prevents the
+        # transaction from becoming idle. Snapshot Read-Only Transactions: Snapshot read-
+        # only transactions provides a simpler method than locking read-write
+        # transactions for doing several consistent reads. However, this type of
+        # transaction does not support writes. Snapshot transactions do not take locks.
+        # Instead, they work by choosing a Cloud Spanner timestamp, then executing all
+        # reads at that timestamp. Since they do not acquire locks, they do not block
+        # concurrent read-write transactions. Unlike locking read-write transactions,
+        # snapshot read-only transactions never abort. They can fail if the chosen read
+        # timestamp is garbage collected; however, the default garbage collection policy
+        # is generous enough that most applications do not need to worry about this in
+        # practice. Snapshot read-only transactions do not need to call Commit or
+        # Rollback (and in fact are not permitted to do so). To execute a snapshot
+        # transaction, the client specifies a timestamp bound, which tells Cloud Spanner
+        # how to choose a read timestamp. The types of timestamp bound are: - Strong (
+        # the default). - Bounded staleness. - Exact staleness. If the Cloud Spanner
+        # database to be read is geographically distributed, stale read-only
+        # transactions can execute more quickly than strong or read-write transaction,
+        # because they are able to execute far from the leader replica. Each type of
+        # timestamp bound is discussed in detail below. Strong: Strong reads are
+        # guaranteed to see the effects of all transactions that have committed before
+        # the start of the read. Furthermore, all rows yielded by a single read are
+        # consistent with each other -- if any part of the read observes a transaction,
+        # all parts of the read see the transaction. Strong reads are not repeatable:
+        # two consecutive strong read-only transactions might return inconsistent
+        # results if there are concurrent writes. If consistency across reads is
+        # required, the reads should be executed within a transaction or at an exact
+        # read timestamp. See TransactionOptions.ReadOnly.strong. Exact Staleness: These
+        # timestamp bounds execute reads at a user-specified timestamp. Reads at a
+        # timestamp are guaranteed to see a consistent prefix of the global transaction
+        # history: they observe modifications done by all transactions with a commit
+        # timestamp less than or equal to the read timestamp, and observe none of the
+        # modifications done by transactions with a larger commit timestamp. They will
+        # block until all conflicting transactions that may be assigned commit
         # timestamps <= the read timestamp have finished. The timestamp can either be
         # expressed as an absolute Cloud Spanner commit timestamp or a staleness
         # relative to the current time. These modes do not require a "negotiation phase"
@@ -4421,49 +4433,50 @@ module Google
         # committing the retry, the client should execute the retry in the same session
         # as the original attempt. The original session's lock priority increases with
         # each consecutive abort, meaning that each attempt has a slightly better chance
-        # of success than the previous. Under some circumstances (e.g., many
+        # of success than the previous. Under some circumstances (for example, many
         # transactions attempting to modify the same row(s)), a transaction can abort
         # many times in a short period before successfully committing. Thus, it is not a
         # good idea to cap the number of retries a transaction can attempt; instead, it
-        # is better to limit the total amount of wall time spent retrying. Idle
-        # Transactions: A transaction is considered idle if it has no outstanding reads
-        # or SQL queries and has not started a read or SQL query within the last 10
-        # seconds. Idle transactions can be aborted by Cloud Spanner so that they don't
-        # hold on to locks indefinitely. In that case, the commit will fail with error `
-        # ABORTED`. If this behavior is undesirable, periodically executing a simple SQL
-        # query in the transaction (e.g., `SELECT 1`) prevents the transaction from
-        # becoming idle. Snapshot Read-Only Transactions: Snapshot read-only
-        # transactions provides a simpler method than locking read-write transactions
-        # for doing several consistent reads. However, this type of transaction does not
-        # support writes. Snapshot transactions do not take locks. Instead, they work by
-        # choosing a Cloud Spanner timestamp, then executing all reads at that timestamp.
-        # Since they do not acquire locks, they do not block concurrent read-write
-        # transactions. Unlike locking read-write transactions, snapshot read-only
-        # transactions never abort. They can fail if the chosen read timestamp is
-        # garbage collected; however, the default garbage collection policy is generous
-        # enough that most applications do not need to worry about this in practice.
-        # Snapshot read-only transactions do not need to call Commit or Rollback (and in
-        # fact are not permitted to do so). To execute a snapshot transaction, the
-        # client specifies a timestamp bound, which tells Cloud Spanner how to choose a
-        # read timestamp. The types of timestamp bound are: - Strong (the default). -
-        # Bounded staleness. - Exact staleness. If the Cloud Spanner database to be read
-        # is geographically distributed, stale read-only transactions can execute more
-        # quickly than strong or read-write transaction, because they are able to
-        # execute far from the leader replica. Each type of timestamp bound is discussed
-        # in detail below. Strong: Strong reads are guaranteed to see the effects of all
-        # transactions that have committed before the start of the read. Furthermore,
-        # all rows yielded by a single read are consistent with each other -- if any
-        # part of the read observes a transaction, all parts of the read see the
-        # transaction. Strong reads are not repeatable: two consecutive strong read-only
-        # transactions might return inconsistent results if there are concurrent writes.
-        # If consistency across reads is required, the reads should be executed within a
-        # transaction or at an exact read timestamp. See TransactionOptions.ReadOnly.
-        # strong. Exact Staleness: These timestamp bounds execute reads at a user-
-        # specified timestamp. Reads at a timestamp are guaranteed to see a consistent
-        # prefix of the global transaction history: they observe modifications done by
-        # all transactions with a commit timestamp <= the read timestamp, and observe
-        # none of the modifications done by transactions with a larger commit timestamp.
-        # They will block until all conflicting transactions that may be assigned commit
+        # is better to limit the total amount of time spent retrying. Idle Transactions:
+        # A transaction is considered idle if it has no outstanding reads or SQL queries
+        # and has not started a read or SQL query within the last 10 seconds. Idle
+        # transactions can be aborted by Cloud Spanner so that they don't hold on to
+        # locks indefinitely. If an idle transaction is aborted, the commit will fail
+        # with error `ABORTED`. If this behavior is undesirable, periodically executing
+        # a simple SQL query in the transaction (for example, `SELECT 1`) prevents the
+        # transaction from becoming idle. Snapshot Read-Only Transactions: Snapshot read-
+        # only transactions provides a simpler method than locking read-write
+        # transactions for doing several consistent reads. However, this type of
+        # transaction does not support writes. Snapshot transactions do not take locks.
+        # Instead, they work by choosing a Cloud Spanner timestamp, then executing all
+        # reads at that timestamp. Since they do not acquire locks, they do not block
+        # concurrent read-write transactions. Unlike locking read-write transactions,
+        # snapshot read-only transactions never abort. They can fail if the chosen read
+        # timestamp is garbage collected; however, the default garbage collection policy
+        # is generous enough that most applications do not need to worry about this in
+        # practice. Snapshot read-only transactions do not need to call Commit or
+        # Rollback (and in fact are not permitted to do so). To execute a snapshot
+        # transaction, the client specifies a timestamp bound, which tells Cloud Spanner
+        # how to choose a read timestamp. The types of timestamp bound are: - Strong (
+        # the default). - Bounded staleness. - Exact staleness. If the Cloud Spanner
+        # database to be read is geographically distributed, stale read-only
+        # transactions can execute more quickly than strong or read-write transaction,
+        # because they are able to execute far from the leader replica. Each type of
+        # timestamp bound is discussed in detail below. Strong: Strong reads are
+        # guaranteed to see the effects of all transactions that have committed before
+        # the start of the read. Furthermore, all rows yielded by a single read are
+        # consistent with each other -- if any part of the read observes a transaction,
+        # all parts of the read see the transaction. Strong reads are not repeatable:
+        # two consecutive strong read-only transactions might return inconsistent
+        # results if there are concurrent writes. If consistency across reads is
+        # required, the reads should be executed within a transaction or at an exact
+        # read timestamp. See TransactionOptions.ReadOnly.strong. Exact Staleness: These
+        # timestamp bounds execute reads at a user-specified timestamp. Reads at a
+        # timestamp are guaranteed to see a consistent prefix of the global transaction
+        # history: they observe modifications done by all transactions with a commit
+        # timestamp less than or equal to the read timestamp, and observe none of the
+        # modifications done by transactions with a larger commit timestamp. They will
+        # block until all conflicting transactions that may be assigned commit
         # timestamps <= the read timestamp have finished. The timestamp can either be
         # expressed as an absolute Cloud Spanner commit timestamp or a staleness
         # relative to the current time. These modes do not require a "negotiation phase"

data/lib/google/apis/spanner_v1/gem_version.rb

@@ -16,13 +16,13 @@ module Google
   module Apis
     module SpannerV1
       # Version of the google-apis-spanner_v1 gem
-      GEM_VERSION = "0.18.0"
+      GEM_VERSION = "0.22.0"
 
       # Version of the code generator used to generate this client
       GENERATOR_VERSION = "0.4.0"
 
       # Revision of the discovery document this client was generated from
-      REVISION = "20210825"
+      REVISION = "20211203"
     end
   end
 end

data/lib/google/apis/spanner_v1/service.rb

@@ -1129,7 +1129,9 @@ module Google
         end
         
         # Drops (aka deletes) a Cloud Spanner database. Completed backups for the
-        # database will be retained according to their `expire_time`.
+        # database will be retained according to their `expire_time`. Note: Cloud
+        # Spanner might continue to accept requests for a few seconds after the database
+        # has been deleted.
         # @param [String] database
         #   Required. The database to be dropped.
         # @param [String] fields

metadata

@@ -1,14 +1,14 @@
 --- !ruby/object:Gem::Specification
 name: google-apis-spanner_v1
 version: !ruby/object:Gem::Version
-  version: 0.18.0
+  version: 0.22.0
 platform: ruby
 authors:
 - Google LLC
 autorequire: 
 bindir: bin
 cert_chain: []
-date: 2021-09-06 00:00:00.000000000 Z
+date: 2022-01-10 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: google-apis-core
@@ -57,9 +57,9 @@ licenses:
 - Apache-2.0
 metadata:
   bug_tracker_uri: https://github.com/googleapis/google-api-ruby-client/issues
-  changelog_uri: https://github.com/googleapis/google-api-ruby-client/tree/master/generated/google-apis-spanner_v1/CHANGELOG.md
-  documentation_uri: https://googleapis.dev/ruby/google-apis-spanner_v1/v0.18.0
-  source_code_uri: https://github.com/googleapis/google-api-ruby-client/tree/master/generated/google-apis-spanner_v1
+  changelog_uri: https://github.com/googleapis/google-api-ruby-client/tree/main/generated/google-apis-spanner_v1/CHANGELOG.md
+  documentation_uri: https://googleapis.dev/ruby/google-apis-spanner_v1/v0.22.0
+  source_code_uri: https://github.com/googleapis/google-api-ruby-client/tree/main/generated/google-apis-spanner_v1
 post_install_message: 
 rdoc_options: []
 require_paths:
@@ -75,7 +75,7 @@ required_rubygems_version: !ruby/object:Gem::Requirement
     - !ruby/object:Gem::Version
       version: '0'
 requirements: []
-rubygems_version: 3.2.17
+rubygems_version: 3.3.4
 signing_key: 
 specification_version: 4
 summary: Simple REST client for Cloud Spanner API V1