google-apis-spanner_v1 0.15.0 → 0.19.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 841f47e49585a9b462f1914af15f5e329bc3bdb97ee9f964dee6044b72259bd6
-  data.tar.gz: 0f2c84cd89461e41a82d96403472dd72a68b1fb2850255f5fb290d10ac96a1a0
+  metadata.gz: d2a066cde62010b9e3316bf3577a4833c6bc909f6ddeff9746e9bfa01415d2ec
+  data.tar.gz: 7921a7d949a8003b299858b58cbf4849a33adf8341e3dca210f9ea22ae4be94d
 SHA512:
-  metadata.gz: ddb44f893976b7f56b2d08d77d11e87666f93c00a0a25dba96c12904b1bd160e4aba2c574e72f1019f26df022a10bfebe8cfd80c4902cfd2c69f32110fdfed7c
-  data.tar.gz: b0430f0754171790362e5611f3c70ddbe4621a04f503df2d127a06fe844d2d19b9cab533bf0780bdd20473a47cb1abad608f4696e22bdf527c50c209dda778ac
+  metadata.gz: eb511303a6979888a2bc73ce005c59b6fc21ce0a7f19a2bbd04ccba3b74f607dc911152fcfa77123d0e2da6a388e371f277b3684368b0c8a99beaa8486d04725
+  data.tar.gz: 1c75f9196ced0547c7d475d24a8ade964acab87aa1e440a9de228bca9f15c6ab390b92a89698de09b4f207eb32f1ca6727a970336d521b471aae6e4f4f6bac53

data/CHANGELOG.md

@@ -1,5 +1,21 @@
 # Release history for google-apis-spanner_v1
 
+### v0.19.0 (2021-09-27)
+
+* Regenerated from discovery document revision 20210914
+
+### v0.18.0 (2021-08-30)
+
+* Regenerated from discovery document revision 20210825
+
+### v0.17.0 (2021-08-21)
+
+* Regenerated from discovery document revision 20210816
+
+### v0.16.0 (2021-07-31)
+
+* Regenerated from discovery document revision 20210723
+
 ### v0.15.0 (2021-07-12)
 
 * Regenerated from discovery document revision 20210703

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"
@@ -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"
@@ -1651,16 +1653,16 @@ module Google
         # resources. They can be used to control how resource metrics are aggregated.
         # And they can be used as arguments to policy management rules (e.g. route,
         # firewall, load balancing, etc.). * Label keys must be between 1 and 63
-        # characters long and must conform to the following regular expression: `[a-z]([-
-        # a-z0-9]*[a-z0-9])?`. * Label values must be between 0 and 63 characters long
-        # and must conform to the regular expression `([a-z]([-a-z0-9]*[a-z0-9])?)?`. *
-        # No more than 64 labels can be associated with a given resource. See https://
-        # goo.gl/xmQnxf for more information on and examples of labels. If you plan to
-        # use labels in your own code, please note that additional characters may be
-        # allowed in the future. And so you are advised to use an internal label
-        # representation, such as JSON, which doesn't rely upon specific characters
-        # being disallowed. For example, representing labels as the string: name + "_" +
-        # value would prove problematic if we were to allow "_" in a future release.
+        # characters long and must conform to the following regular expression: `a-z`0,
+        # 62``. * Label values must be between 0 and 63 characters long and must conform
+        # to the regular expression `[a-z0-9_-]`0,63``. * No more than 64 labels can be
+        # associated with a given resource. See https://goo.gl/xmQnxf for more
+        # information on and examples of labels. If you plan to use labels in your own
+        # code, please note that additional characters may be allowed in the future. And
+        # so you are advised to use an internal label representation, such as JSON,
+        # which doesn't rely upon specific characters being disallowed. For example,
+        # representing labels as the string: name + "_" + value would prove problematic
+        # if we were to allow "_" in a future release.
         # Corresponds to the JSON property `labels`
         # @return [Hash<String,String>]
         attr_accessor :labels
@@ -1673,17 +1675,20 @@ module Google
         # @return [String]
         attr_accessor :name
       
-        # The number of nodes allocated to this instance. This may be zero in API
-        # responses for instances that are not yet in state `READY`. See [the
-        # documentation](https://cloud.google.com/spanner/docs/instances#node_count) for
-        # more information about nodes.
+        # The number of nodes allocated to this instance. At most one of either
+        # node_count or processing_units should be present in the message. This may be
+        # zero in API responses for instances that are not yet in state `READY`. See [
+        # the documentation](https://cloud.google.com/spanner/docs/compute-capacity) for
+        # more information about nodes and processing units.
         # Corresponds to the JSON property `nodeCount`
         # @return [Fixnum]
         attr_accessor :node_count
       
         # The number of processing units allocated to this instance. At most one of
         # processing_units or node_count should be present in the message. This may be
-        # zero in API responses for instances that are not yet in state `READY`.
+        # zero in API responses for instances that are not yet in state `READY`. See [
+        # the documentation](https://cloud.google.com/spanner/docs/compute-capacity) for
+        # more information about nodes and processing units.
         # Corresponds to the JSON property `processingUnits`
         # @return [Fixnum]
         attr_accessor :processing_units
@@ -1729,7 +1734,7 @@ module Google
         attr_accessor :leader_options
       
         # A unique identifier for the instance configuration. Values are of the form `
-        # projects//instanceConfigs/a-z*`
+        # projects//instanceConfigs/a-z*`.
         # Corresponds to the JSON property `name`
         # @return [String]
         attr_accessor :name
@@ -2934,7 +2939,7 @@ module Google
       # 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
+      # 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
@@ -3788,7 +3793,7 @@ module Google
         # 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
+        # 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`
@@ -4054,49 +4059,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"
@@ -4249,49 +4255,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"
@@ -4418,49 +4425,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.15.0"
+      GEM_VERSION = "0.19.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 = "20210703"
+      REVISION = "20210914"
     end
   end
 end

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

@@ -350,7 +350,7 @@ module Google
         # the format `/operations/` and can be used to track the instance modification.
         # The metadata field type is UpdateInstanceMetadata. The response field type is
         # Instance, if successful. Authorization requires `spanner.instances.update`
-        # permission on resource name.
+        # permission on the resource name.
         # @param [String] name
         #   Required. A unique identifier for the instance, which cannot be changed after
         #   the instance is created. Values are of the form `projects//instances/a-z*[a-z0-

data/lib/google/apis/spanner_v1.rb

@@ -30,7 +30,7 @@ module Google
       # This is NOT the gem version.
       VERSION = 'V1'
 
-      # See, edit, configure, and delete your Google Cloud Platform data
+      # See, edit, configure, and delete your Google Cloud data and see the email address for your Google Account.
       AUTH_CLOUD_PLATFORM = 'https://www.googleapis.com/auth/cloud-platform'
 
       # Administer your Spanner databases

metadata

@@ -1,14 +1,14 @@
 --- !ruby/object:Gem::Specification
 name: google-apis-spanner_v1
 version: !ruby/object:Gem::Version
-  version: 0.15.0
+  version: 0.19.0
 platform: ruby
 authors:
 - Google LLC
 autorequire: 
 bindir: bin
 cert_chain: []
-date: 2021-07-19 00:00:00.000000000 Z
+date: 2021-10-04 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: google-apis-core
@@ -58,7 +58,7 @@ licenses:
 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.15.0
+  documentation_uri: https://googleapis.dev/ruby/google-apis-spanner_v1/v0.19.0
   source_code_uri: https://github.com/googleapis/google-api-ruby-client/tree/master/generated/google-apis-spanner_v1
 post_install_message: 
 rdoc_options: []