google-apis-spanner_v1 0.25.0 → 0.26.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 51541562e98ca4e9c993afc467f0a98ff8adaa1eda1805c36bafd9997211b2bc
-  data.tar.gz: ddae8e9f8a2915b8462b04e92914d52f13e1707953dd55bb887473a9e2ba773a
+  metadata.gz: eec80b1ffbe8702f803572d10fbe6cd14e056cf35fa6c7a4cd12ba3ba1df8b11
+  data.tar.gz: ea92fce3176c283dbd99e663a9e7ca913e9a2d1a74f2cdc9ccee830f49bf4aa6
 SHA512:
-  metadata.gz: dc983c308f4d10749bbf5e7fb820069f8644ba3afb151c60f8f2ae15522aa813c3de799f45b359ec142103b5aee7c7bfe45f0f9dba9e0d4180b274f9953f816e
-  data.tar.gz: 8db003dacedd2fd9421d39537dfd0504241013e30a08eec8951b3e8f0a99ea8916086b55829e532ceca0386a8f99f6f70d2cfeb71bae1ac3b56c49cc859bea3b
+  metadata.gz: 03ba93f0e90b0928df96d00329fd83e79689d6eb096d0bb07b43ea3c0fea079c04be2800beebdfccc1b01a927d7bac048994563135ff86f9e2a6b51dc8ee9833
+  data.tar.gz: 402417d83a693a56b0db7ea651feb91254ec2e3de67d46136a077f1f76e452d9efae75bd6fd4b1d5eb1103df7f5c2567137892c2003b1110cd433552e6a7b398

data/CHANGELOG.md

@@ -1,5 +1,9 @@
 # Release history for google-apis-spanner_v1
 
+### v0.26.0 (2022-03-30)
+
+* Regenerated from discovery document revision 20220326
+
 ### v0.25.0 (2022-03-19)
 
 * Regenerated from discovery document revision 20220310

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

@@ -233,7 +233,7 @@ module Google
         # count towards the one transaction limit). After the active transaction is
         # completed, the session can immediately be re-used for the next transaction. It
         # is not necessary to create a new session for each transaction. Transaction
-        # Modes: Cloud Spanner supports three transaction modes: 1. Locking read-write.
+        # modes: Cloud Spanner supports three transaction modes: 1. Locking read-write.
         # This type of transaction is the only way to write data into Cloud Spanner.
         # These transactions rely on pessimistic locking and, if necessary, two-phase
         # commit. Locking read-write transactions may abort, requiring the application
@@ -249,9 +249,9 @@ module Google
         # simpler semantics and are almost always faster. In particular, read-only
         # transactions do not take locks, so they do not conflict with read-write
         # transactions. As a consequence of not taking locks, they also do not abort, so
-        # retry loops are not needed. Transactions may only read/write data in a single
-        # database. They may, however, read/write data in different tables within that
-        # database. Locking Read-Write Transactions: Locking transactions may be used to
+        # retry loops are not needed. Transactions may only read-write data in a single
+        # database. They may, however, read-write data in different tables within that
+        # database. Locking read-write transactions: Locking transactions may be used to
         # atomically read-modify-write data anywhere in a database. This type of
         # transaction is externally consistent. Clients should attempt to minimize the
         # amount of time a transaction is active. Faster transactions commit with higher
@@ -270,7 +270,7 @@ module Google
         # Cloud Spanner makes no guarantees about how long the transaction's locks were
         # held for. It is an error to use Cloud Spanner locks for any sort of mutual
         # exclusion other than between Cloud Spanner transactions themselves. Retrying
-        # Aborted Transactions: When a transaction aborts, the application can choose to
+        # aborted transactions: When a transaction aborts, the application can choose to
         # retry the whole transaction again. To maximize the chances of successfully
         # 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
@@ -279,14 +279,14 @@ module Google
         # 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 time spent retrying. Idle Transactions:
+        # 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-
+        # 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.
@@ -302,7 +302,7 @@ module Google
         # 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,
+        # transactions can execute more quickly than strong or read-write transactions,
         # 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
@@ -312,7 +312,7 @@ module Google
         # 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
+        # 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
@@ -326,7 +326,7 @@ module Google
         # equivalent boundedly stale concurrency modes. On the other hand, boundedly
         # stale reads usually return fresher results. See TransactionOptions.ReadOnly.
         # read_timestamp and TransactionOptions.ReadOnly.exact_staleness. Bounded
-        # Staleness: Bounded staleness modes allow Cloud Spanner to pick the read
+        # staleness: Bounded staleness modes allow Cloud Spanner to pick the read
         # timestamp, subject to a user-provided staleness bound. Cloud Spanner chooses
         # the newest timestamp within the staleness bound that allows execution of the
         # reads at the closest available replica without blocking. All rows yielded are
@@ -343,51 +343,54 @@ module Google
         # timestamp negotiation requires up-front knowledge of which rows will be read,
         # it can only be used with single-use read-only transactions. See
         # TransactionOptions.ReadOnly.max_staleness and TransactionOptions.ReadOnly.
-        # min_read_timestamp. Old Read Timestamps and Garbage Collection: Cloud Spanner
+        # min_read_timestamp. Old read timestamps and garbage collection: Cloud Spanner
         # continuously garbage collects deleted and overwritten data in the background
         # to reclaim storage space. This process is known as "version GC". By default,
         # version GC reclaims versions after they are one hour old. Because of this,
         # Cloud Spanner cannot perform reads at read timestamps more than one hour in
         # the past. This restriction also applies to in-progress reads and/or SQL
         # queries whose timestamp become too old while executing. Reads and SQL queries
-        # with too-old read timestamps fail with the error `FAILED_PRECONDITION`.
-        # Partitioned DML Transactions: Partitioned DML transactions are used to execute
-        # DML statements with a different execution strategy that provides different,
-        # and often better, scalability properties for large, table-wide operations than
-        # DML in a ReadWrite transaction. Smaller scoped statements, such as an OLTP
-        # workload, should prefer using ReadWrite transactions. Partitioned DML
-        # partitions the keyspace and runs the DML statement on each partition in
-        # separate, internal transactions. These transactions commit automatically when
-        # complete, and run independently from one another. To reduce lock contention,
-        # this execution strategy only acquires read locks on rows that match the WHERE
-        # clause of the statement. Additionally, the smaller per-partition transactions
-        # hold locks for less time. That said, Partitioned DML is not a drop-in
-        # replacement for standard DML used in ReadWrite transactions. - The DML
-        # statement must be fully-partitionable. Specifically, the statement must be
-        # expressible as the union of many statements which each access only a single
-        # row of the table. - The statement is not applied atomically to all rows of the
-        # table. Rather, the statement is applied atomically to partitions of the table,
-        # in independent transactions. Secondary index rows are updated atomically with
-        # the base table rows. - Partitioned DML does not guarantee exactly-once
-        # execution semantics against a partition. The statement will be applied at
-        # least once to each partition. It is strongly recommended that the DML
-        # statement should be idempotent to avoid unexpected results. For instance, it
-        # is potentially dangerous to run a statement such as `UPDATE table SET column =
-        # column + 1` as it could be run multiple times against some rows. - The
-        # partitions are committed automatically - there is no support for Commit or
-        # Rollback. If the call returns an error, or if the client issuing the
-        # ExecuteSql call dies, it is possible that some rows had the statement executed
-        # on them successfully. It is also possible that statement was never executed
-        # against other rows. - Partitioned DML transactions may only contain the
-        # execution of a single DML statement via ExecuteSql or ExecuteStreamingSql. -
-        # If any error is encountered during the execution of the partitioned DML
-        # operation (for instance, a UNIQUE INDEX violation, division by zero, or a
-        # value that cannot be stored due to schema constraints), then the operation is
-        # stopped at that point and an error is returned. It is possible that at this
-        # point, some partitions have been committed (or even committed multiple times),
-        # and other partitions have not been run at all. Given the above, Partitioned
-        # DML is good fit for large, database-wide, operations that are idempotent, such
-        # as deleting old rows from a very large table.
+        # with too-old read timestamps fail with the error `FAILED_PRECONDITION`. You
+        # can configure and extend the `VERSION_RETENTION_PERIOD` of a database up to a
+        # period as long as one week, which allows Cloud Spanner to perform reads up to
+        # one week in the past. Partitioned DML transactions: Partitioned DML
+        # transactions are used to execute DML statements with a different execution
+        # strategy that provides different, and often better, scalability properties for
+        # large, table-wide operations than DML in a ReadWrite transaction. Smaller
+        # scoped statements, such as an OLTP workload, should prefer using ReadWrite
+        # transactions. Partitioned DML partitions the keyspace and runs the DML
+        # statement on each partition in separate, internal transactions. These
+        # transactions commit automatically when complete, and run independently from
+        # one another. To reduce lock contention, this execution strategy only acquires
+        # read locks on rows that match the WHERE clause of the statement. Additionally,
+        # the smaller per-partition transactions hold locks for less time. That said,
+        # Partitioned DML is not a drop-in replacement for standard DML used in
+        # ReadWrite transactions. - The DML statement must be fully-partitionable.
+        # Specifically, the statement must be expressible as the union of many
+        # statements which each access only a single row of the table. - The statement
+        # is not applied atomically to all rows of the table. Rather, the statement is
+        # applied atomically to partitions of the table, in independent transactions.
+        # Secondary index rows are updated atomically with the base table rows. -
+        # Partitioned DML does not guarantee exactly-once execution semantics against a
+        # partition. The statement will be applied at least once to each partition. It
+        # is strongly recommended that the DML statement should be idempotent to avoid
+        # unexpected results. For instance, it is potentially dangerous to run a
+        # statement such as `UPDATE table SET column = column + 1` as it could be run
+        # multiple times against some rows. - The partitions are committed automatically
+        # - there is no support for Commit or Rollback. If the call returns an error, or
+        # if the client issuing the ExecuteSql call dies, it is possible that some rows
+        # had the statement executed on them successfully. It is also possible that
+        # statement was never executed against other rows. - Partitioned DML
+        # transactions may only contain the execution of a single DML statement via
+        # ExecuteSql or ExecuteStreamingSql. - If any error is encountered during the
+        # execution of the partitioned DML operation (for instance, a UNIQUE INDEX
+        # violation, division by zero, or a value that cannot be stored due to schema
+        # constraints), then the operation is stopped at that point and an error is
+        # returned. It is possible that at this point, some partitions have been
+        # committed (or even committed multiple times), and other partitions have not
+        # been run at all. Given the above, Partitioned DML is good fit for large,
+        # database-wide, operations that are idempotent, such as deleting old rows from
+        # a very large table.
         # Corresponds to the JSON property `options`
         # @return [Google::Apis::SpannerV1::TransactionOptions]
         attr_accessor :options
@@ -545,7 +548,7 @@ module Google
         # count towards the one transaction limit). After the active transaction is
         # completed, the session can immediately be re-used for the next transaction. It
         # is not necessary to create a new session for each transaction. Transaction
-        # Modes: Cloud Spanner supports three transaction modes: 1. Locking read-write.
+        # modes: Cloud Spanner supports three transaction modes: 1. Locking read-write.
         # This type of transaction is the only way to write data into Cloud Spanner.
         # These transactions rely on pessimistic locking and, if necessary, two-phase
         # commit. Locking read-write transactions may abort, requiring the application
@@ -561,9 +564,9 @@ module Google
         # simpler semantics and are almost always faster. In particular, read-only
         # transactions do not take locks, so they do not conflict with read-write
         # transactions. As a consequence of not taking locks, they also do not abort, so
-        # retry loops are not needed. Transactions may only read/write data in a single
-        # database. They may, however, read/write data in different tables within that
-        # database. Locking Read-Write Transactions: Locking transactions may be used to
+        # retry loops are not needed. Transactions may only read-write data in a single
+        # database. They may, however, read-write data in different tables within that
+        # database. Locking read-write transactions: Locking transactions may be used to
         # atomically read-modify-write data anywhere in a database. This type of
         # transaction is externally consistent. Clients should attempt to minimize the
         # amount of time a transaction is active. Faster transactions commit with higher
@@ -582,7 +585,7 @@ module Google
         # Cloud Spanner makes no guarantees about how long the transaction's locks were
         # held for. It is an error to use Cloud Spanner locks for any sort of mutual
         # exclusion other than between Cloud Spanner transactions themselves. Retrying
-        # Aborted Transactions: When a transaction aborts, the application can choose to
+        # aborted transactions: When a transaction aborts, the application can choose to
         # retry the whole transaction again. To maximize the chances of successfully
         # 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
@@ -591,14 +594,14 @@ module Google
         # 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 time spent retrying. Idle Transactions:
+        # 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-
+        # 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.
@@ -614,7 +617,7 @@ module Google
         # 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,
+        # transactions can execute more quickly than strong or read-write transactions,
         # 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
@@ -624,7 +627,7 @@ module Google
         # 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
+        # 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
@@ -638,7 +641,7 @@ module Google
         # equivalent boundedly stale concurrency modes. On the other hand, boundedly
         # stale reads usually return fresher results. See TransactionOptions.ReadOnly.
         # read_timestamp and TransactionOptions.ReadOnly.exact_staleness. Bounded
-        # Staleness: Bounded staleness modes allow Cloud Spanner to pick the read
+        # staleness: Bounded staleness modes allow Cloud Spanner to pick the read
         # timestamp, subject to a user-provided staleness bound. Cloud Spanner chooses
         # the newest timestamp within the staleness bound that allows execution of the
         # reads at the closest available replica without blocking. All rows yielded are
@@ -655,51 +658,54 @@ module Google
         # timestamp negotiation requires up-front knowledge of which rows will be read,
         # it can only be used with single-use read-only transactions. See
         # TransactionOptions.ReadOnly.max_staleness and TransactionOptions.ReadOnly.
-        # min_read_timestamp. Old Read Timestamps and Garbage Collection: Cloud Spanner
+        # min_read_timestamp. Old read timestamps and garbage collection: Cloud Spanner
         # continuously garbage collects deleted and overwritten data in the background
         # to reclaim storage space. This process is known as "version GC". By default,
         # version GC reclaims versions after they are one hour old. Because of this,
         # Cloud Spanner cannot perform reads at read timestamps more than one hour in
         # the past. This restriction also applies to in-progress reads and/or SQL
         # queries whose timestamp become too old while executing. Reads and SQL queries
-        # with too-old read timestamps fail with the error `FAILED_PRECONDITION`.
-        # Partitioned DML Transactions: Partitioned DML transactions are used to execute
-        # DML statements with a different execution strategy that provides different,
-        # and often better, scalability properties for large, table-wide operations than
-        # DML in a ReadWrite transaction. Smaller scoped statements, such as an OLTP
-        # workload, should prefer using ReadWrite transactions. Partitioned DML
-        # partitions the keyspace and runs the DML statement on each partition in
-        # separate, internal transactions. These transactions commit automatically when
-        # complete, and run independently from one another. To reduce lock contention,
-        # this execution strategy only acquires read locks on rows that match the WHERE
-        # clause of the statement. Additionally, the smaller per-partition transactions
-        # hold locks for less time. That said, Partitioned DML is not a drop-in
-        # replacement for standard DML used in ReadWrite transactions. - The DML
-        # statement must be fully-partitionable. Specifically, the statement must be
-        # expressible as the union of many statements which each access only a single
-        # row of the table. - The statement is not applied atomically to all rows of the
-        # table. Rather, the statement is applied atomically to partitions of the table,
-        # in independent transactions. Secondary index rows are updated atomically with
-        # the base table rows. - Partitioned DML does not guarantee exactly-once
-        # execution semantics against a partition. The statement will be applied at
-        # least once to each partition. It is strongly recommended that the DML
-        # statement should be idempotent to avoid unexpected results. For instance, it
-        # is potentially dangerous to run a statement such as `UPDATE table SET column =
-        # column + 1` as it could be run multiple times against some rows. - The
-        # partitions are committed automatically - there is no support for Commit or
-        # Rollback. If the call returns an error, or if the client issuing the
-        # ExecuteSql call dies, it is possible that some rows had the statement executed
-        # on them successfully. It is also possible that statement was never executed
-        # against other rows. - Partitioned DML transactions may only contain the
-        # execution of a single DML statement via ExecuteSql or ExecuteStreamingSql. -
-        # If any error is encountered during the execution of the partitioned DML
-        # operation (for instance, a UNIQUE INDEX violation, division by zero, or a
-        # value that cannot be stored due to schema constraints), then the operation is
-        # stopped at that point and an error is returned. It is possible that at this
-        # point, some partitions have been committed (or even committed multiple times),
-        # and other partitions have not been run at all. Given the above, Partitioned
-        # DML is good fit for large, database-wide, operations that are idempotent, such
-        # as deleting old rows from a very large table.
+        # with too-old read timestamps fail with the error `FAILED_PRECONDITION`. You
+        # can configure and extend the `VERSION_RETENTION_PERIOD` of a database up to a
+        # period as long as one week, which allows Cloud Spanner to perform reads up to
+        # one week in the past. Partitioned DML transactions: Partitioned DML
+        # transactions are used to execute DML statements with a different execution
+        # strategy that provides different, and often better, scalability properties for
+        # large, table-wide operations than DML in a ReadWrite transaction. Smaller
+        # scoped statements, such as an OLTP workload, should prefer using ReadWrite
+        # transactions. Partitioned DML partitions the keyspace and runs the DML
+        # statement on each partition in separate, internal transactions. These
+        # transactions commit automatically when complete, and run independently from
+        # one another. To reduce lock contention, this execution strategy only acquires
+        # read locks on rows that match the WHERE clause of the statement. Additionally,
+        # the smaller per-partition transactions hold locks for less time. That said,
+        # Partitioned DML is not a drop-in replacement for standard DML used in
+        # ReadWrite transactions. - The DML statement must be fully-partitionable.
+        # Specifically, the statement must be expressible as the union of many
+        # statements which each access only a single row of the table. - The statement
+        # is not applied atomically to all rows of the table. Rather, the statement is
+        # applied atomically to partitions of the table, in independent transactions.
+        # Secondary index rows are updated atomically with the base table rows. -
+        # Partitioned DML does not guarantee exactly-once execution semantics against a
+        # partition. The statement will be applied at least once to each partition. It
+        # is strongly recommended that the DML statement should be idempotent to avoid
+        # unexpected results. For instance, it is potentially dangerous to run a
+        # statement such as `UPDATE table SET column = column + 1` as it could be run
+        # multiple times against some rows. - The partitions are committed automatically
+        # - there is no support for Commit or Rollback. If the call returns an error, or
+        # if the client issuing the ExecuteSql call dies, it is possible that some rows
+        # had the statement executed on them successfully. It is also possible that
+        # statement was never executed against other rows. - Partitioned DML
+        # transactions may only contain the execution of a single DML statement via
+        # ExecuteSql or ExecuteStreamingSql. - If any error is encountered during the
+        # execution of the partitioned DML operation (for instance, a UNIQUE INDEX
+        # violation, division by zero, or a value that cannot be stored due to schema
+        # constraints), then the operation is stopped at that point and an error is
+        # returned. It is possible that at this point, some partitions have been
+        # committed (or even committed multiple times), and other partitions have not
+        # been run at all. Given the above, Partitioned DML is good fit for large,
+        # database-wide, operations that are idempotent, such as deleting old rows from
+        # a very large table.
         # Corresponds to the JSON property `singleUseTransaction`
         # @return [Google::Apis::SpannerV1::TransactionOptions]
         attr_accessor :single_use_transaction
@@ -1326,8 +1332,7 @@ module Google
       # A generic empty message that you can re-use to avoid defining duplicated empty
       # messages in your APIs. A typical example is to use it as the request or the
       # response type of an API method. For instance: service Foo ` rpc Bar(google.
-      # protobuf.Empty) returns (google.protobuf.Empty); ` The JSON representation for
-      # `Empty` is empty JSON object ````.
+      # protobuf.Empty) returns (google.protobuf.Empty); `
       class Empty
         include Google::Apis::Core::Hashable
       
@@ -4196,7 +4201,7 @@ module Google
       # count towards the one transaction limit). After the active transaction is
       # completed, the session can immediately be re-used for the next transaction. It
       # is not necessary to create a new session for each transaction. Transaction
-      # Modes: Cloud Spanner supports three transaction modes: 1. Locking read-write.
+      # modes: Cloud Spanner supports three transaction modes: 1. Locking read-write.
       # This type of transaction is the only way to write data into Cloud Spanner.
       # These transactions rely on pessimistic locking and, if necessary, two-phase
       # commit. Locking read-write transactions may abort, requiring the application
@@ -4212,9 +4217,9 @@ module Google
       # simpler semantics and are almost always faster. In particular, read-only
       # transactions do not take locks, so they do not conflict with read-write
       # transactions. As a consequence of not taking locks, they also do not abort, so
-      # retry loops are not needed. Transactions may only read/write data in a single
-      # database. They may, however, read/write data in different tables within that
-      # database. Locking Read-Write Transactions: Locking transactions may be used to
+      # retry loops are not needed. Transactions may only read-write data in a single
+      # database. They may, however, read-write data in different tables within that
+      # database. Locking read-write transactions: Locking transactions may be used to
       # atomically read-modify-write data anywhere in a database. This type of
       # transaction is externally consistent. Clients should attempt to minimize the
       # amount of time a transaction is active. Faster transactions commit with higher
@@ -4233,7 +4238,7 @@ module Google
       # Cloud Spanner makes no guarantees about how long the transaction's locks were
       # held for. It is an error to use Cloud Spanner locks for any sort of mutual
       # exclusion other than between Cloud Spanner transactions themselves. Retrying
-      # Aborted Transactions: When a transaction aborts, the application can choose to
+      # aborted transactions: When a transaction aborts, the application can choose to
       # retry the whole transaction again. To maximize the chances of successfully
       # 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
@@ -4242,14 +4247,14 @@ module Google
       # 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 time spent retrying. Idle Transactions:
+      # 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-
+      # 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.
@@ -4265,7 +4270,7 @@ module Google
       # 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,
+      # transactions can execute more quickly than strong or read-write transactions,
       # 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
@@ -4275,7 +4280,7 @@ module Google
       # 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
+      # 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
@@ -4289,7 +4294,7 @@ module Google
       # equivalent boundedly stale concurrency modes. On the other hand, boundedly
       # stale reads usually return fresher results. See TransactionOptions.ReadOnly.
       # read_timestamp and TransactionOptions.ReadOnly.exact_staleness. Bounded
-      # Staleness: Bounded staleness modes allow Cloud Spanner to pick the read
+      # staleness: Bounded staleness modes allow Cloud Spanner to pick the read
       # timestamp, subject to a user-provided staleness bound. Cloud Spanner chooses
       # the newest timestamp within the staleness bound that allows execution of the
       # reads at the closest available replica without blocking. All rows yielded are
@@ -4306,51 +4311,54 @@ module Google
       # timestamp negotiation requires up-front knowledge of which rows will be read,
       # it can only be used with single-use read-only transactions. See
       # TransactionOptions.ReadOnly.max_staleness and TransactionOptions.ReadOnly.
-      # min_read_timestamp. Old Read Timestamps and Garbage Collection: Cloud Spanner
+      # min_read_timestamp. Old read timestamps and garbage collection: Cloud Spanner
       # continuously garbage collects deleted and overwritten data in the background
       # to reclaim storage space. This process is known as "version GC". By default,
       # version GC reclaims versions after they are one hour old. Because of this,
       # Cloud Spanner cannot perform reads at read timestamps more than one hour in
       # the past. This restriction also applies to in-progress reads and/or SQL
       # queries whose timestamp become too old while executing. Reads and SQL queries
-      # with too-old read timestamps fail with the error `FAILED_PRECONDITION`.
-      # Partitioned DML Transactions: Partitioned DML transactions are used to execute
-      # DML statements with a different execution strategy that provides different,
-      # and often better, scalability properties for large, table-wide operations than
-      # DML in a ReadWrite transaction. Smaller scoped statements, such as an OLTP
-      # workload, should prefer using ReadWrite transactions. Partitioned DML
-      # partitions the keyspace and runs the DML statement on each partition in
-      # separate, internal transactions. These transactions commit automatically when
-      # complete, and run independently from one another. To reduce lock contention,
-      # this execution strategy only acquires read locks on rows that match the WHERE
-      # clause of the statement. Additionally, the smaller per-partition transactions
-      # hold locks for less time. That said, Partitioned DML is not a drop-in
-      # replacement for standard DML used in ReadWrite transactions. - The DML
-      # statement must be fully-partitionable. Specifically, the statement must be
-      # expressible as the union of many statements which each access only a single
-      # row of the table. - The statement is not applied atomically to all rows of the
-      # table. Rather, the statement is applied atomically to partitions of the table,
-      # in independent transactions. Secondary index rows are updated atomically with
-      # the base table rows. - Partitioned DML does not guarantee exactly-once
-      # execution semantics against a partition. The statement will be applied at
-      # least once to each partition. It is strongly recommended that the DML
-      # statement should be idempotent to avoid unexpected results. For instance, it
-      # is potentially dangerous to run a statement such as `UPDATE table SET column =
-      # column + 1` as it could be run multiple times against some rows. - The
-      # partitions are committed automatically - there is no support for Commit or
-      # Rollback. If the call returns an error, or if the client issuing the
-      # ExecuteSql call dies, it is possible that some rows had the statement executed
-      # on them successfully. It is also possible that statement was never executed
-      # against other rows. - Partitioned DML transactions may only contain the
-      # execution of a single DML statement via ExecuteSql or ExecuteStreamingSql. -
-      # If any error is encountered during the execution of the partitioned DML
-      # operation (for instance, a UNIQUE INDEX violation, division by zero, or a
-      # value that cannot be stored due to schema constraints), then the operation is
-      # stopped at that point and an error is returned. It is possible that at this
-      # point, some partitions have been committed (or even committed multiple times),
-      # and other partitions have not been run at all. Given the above, Partitioned
-      # DML is good fit for large, database-wide, operations that are idempotent, such
-      # as deleting old rows from a very large table.
+      # with too-old read timestamps fail with the error `FAILED_PRECONDITION`. You
+      # can configure and extend the `VERSION_RETENTION_PERIOD` of a database up to a
+      # period as long as one week, which allows Cloud Spanner to perform reads up to
+      # one week in the past. Partitioned DML transactions: Partitioned DML
+      # transactions are used to execute DML statements with a different execution
+      # strategy that provides different, and often better, scalability properties for
+      # large, table-wide operations than DML in a ReadWrite transaction. Smaller
+      # scoped statements, such as an OLTP workload, should prefer using ReadWrite
+      # transactions. Partitioned DML partitions the keyspace and runs the DML
+      # statement on each partition in separate, internal transactions. These
+      # transactions commit automatically when complete, and run independently from
+      # one another. To reduce lock contention, this execution strategy only acquires
+      # read locks on rows that match the WHERE clause of the statement. Additionally,
+      # the smaller per-partition transactions hold locks for less time. That said,
+      # Partitioned DML is not a drop-in replacement for standard DML used in
+      # ReadWrite transactions. - The DML statement must be fully-partitionable.
+      # Specifically, the statement must be expressible as the union of many
+      # statements which each access only a single row of the table. - The statement
+      # is not applied atomically to all rows of the table. Rather, the statement is
+      # applied atomically to partitions of the table, in independent transactions.
+      # Secondary index rows are updated atomically with the base table rows. -
+      # Partitioned DML does not guarantee exactly-once execution semantics against a
+      # partition. The statement will be applied at least once to each partition. It
+      # is strongly recommended that the DML statement should be idempotent to avoid
+      # unexpected results. For instance, it is potentially dangerous to run a
+      # statement such as `UPDATE table SET column = column + 1` as it could be run
+      # multiple times against some rows. - The partitions are committed automatically
+      # - there is no support for Commit or Rollback. If the call returns an error, or
+      # if the client issuing the ExecuteSql call dies, it is possible that some rows
+      # had the statement executed on them successfully. It is also possible that
+      # statement was never executed against other rows. - Partitioned DML
+      # transactions may only contain the execution of a single DML statement via
+      # ExecuteSql or ExecuteStreamingSql. - If any error is encountered during the
+      # execution of the partitioned DML operation (for instance, a UNIQUE INDEX
+      # violation, division by zero, or a value that cannot be stored due to schema
+      # constraints), then the operation is stopped at that point and an error is
+      # returned. It is possible that at this point, some partitions have been
+      # committed (or even committed multiple times), and other partitions have not
+      # been run at all. Given the above, Partitioned DML is good fit for large,
+      # database-wide, operations that are idempotent, such as deleting old rows from
+      # a very large table.
       class TransactionOptions
         include Google::Apis::Core::Hashable
       
@@ -4392,7 +4400,7 @@ module Google
         # count towards the one transaction limit). After the active transaction is
         # completed, the session can immediately be re-used for the next transaction. It
         # is not necessary to create a new session for each transaction. Transaction
-        # Modes: Cloud Spanner supports three transaction modes: 1. Locking read-write.
+        # modes: Cloud Spanner supports three transaction modes: 1. Locking read-write.
         # This type of transaction is the only way to write data into Cloud Spanner.
         # These transactions rely on pessimistic locking and, if necessary, two-phase
         # commit. Locking read-write transactions may abort, requiring the application
@@ -4408,9 +4416,9 @@ module Google
         # simpler semantics and are almost always faster. In particular, read-only
         # transactions do not take locks, so they do not conflict with read-write
         # transactions. As a consequence of not taking locks, they also do not abort, so
-        # retry loops are not needed. Transactions may only read/write data in a single
-        # database. They may, however, read/write data in different tables within that
-        # database. Locking Read-Write Transactions: Locking transactions may be used to
+        # retry loops are not needed. Transactions may only read-write data in a single
+        # database. They may, however, read-write data in different tables within that
+        # database. Locking read-write transactions: Locking transactions may be used to
         # atomically read-modify-write data anywhere in a database. This type of
         # transaction is externally consistent. Clients should attempt to minimize the
         # amount of time a transaction is active. Faster transactions commit with higher
@@ -4429,7 +4437,7 @@ module Google
         # Cloud Spanner makes no guarantees about how long the transaction's locks were
         # held for. It is an error to use Cloud Spanner locks for any sort of mutual
         # exclusion other than between Cloud Spanner transactions themselves. Retrying
-        # Aborted Transactions: When a transaction aborts, the application can choose to
+        # aborted transactions: When a transaction aborts, the application can choose to
         # retry the whole transaction again. To maximize the chances of successfully
         # 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
@@ -4438,14 +4446,14 @@ module Google
         # 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 time spent retrying. Idle Transactions:
+        # 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-
+        # 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.
@@ -4461,7 +4469,7 @@ module Google
         # 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,
+        # transactions can execute more quickly than strong or read-write transactions,
         # 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
@@ -4471,7 +4479,7 @@ module Google
         # 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
+        # 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
@@ -4485,7 +4493,7 @@ module Google
         # equivalent boundedly stale concurrency modes. On the other hand, boundedly
         # stale reads usually return fresher results. See TransactionOptions.ReadOnly.
         # read_timestamp and TransactionOptions.ReadOnly.exact_staleness. Bounded
-        # Staleness: Bounded staleness modes allow Cloud Spanner to pick the read
+        # staleness: Bounded staleness modes allow Cloud Spanner to pick the read
         # timestamp, subject to a user-provided staleness bound. Cloud Spanner chooses
         # the newest timestamp within the staleness bound that allows execution of the
         # reads at the closest available replica without blocking. All rows yielded are
@@ -4502,51 +4510,54 @@ module Google
         # timestamp negotiation requires up-front knowledge of which rows will be read,
         # it can only be used with single-use read-only transactions. See
         # TransactionOptions.ReadOnly.max_staleness and TransactionOptions.ReadOnly.
-        # min_read_timestamp. Old Read Timestamps and Garbage Collection: Cloud Spanner
+        # min_read_timestamp. Old read timestamps and garbage collection: Cloud Spanner
         # continuously garbage collects deleted and overwritten data in the background
         # to reclaim storage space. This process is known as "version GC". By default,
         # version GC reclaims versions after they are one hour old. Because of this,
         # Cloud Spanner cannot perform reads at read timestamps more than one hour in
         # the past. This restriction also applies to in-progress reads and/or SQL
         # queries whose timestamp become too old while executing. Reads and SQL queries
-        # with too-old read timestamps fail with the error `FAILED_PRECONDITION`.
-        # Partitioned DML Transactions: Partitioned DML transactions are used to execute
-        # DML statements with a different execution strategy that provides different,
-        # and often better, scalability properties for large, table-wide operations than
-        # DML in a ReadWrite transaction. Smaller scoped statements, such as an OLTP
-        # workload, should prefer using ReadWrite transactions. Partitioned DML
-        # partitions the keyspace and runs the DML statement on each partition in
-        # separate, internal transactions. These transactions commit automatically when
-        # complete, and run independently from one another. To reduce lock contention,
-        # this execution strategy only acquires read locks on rows that match the WHERE
-        # clause of the statement. Additionally, the smaller per-partition transactions
-        # hold locks for less time. That said, Partitioned DML is not a drop-in
-        # replacement for standard DML used in ReadWrite transactions. - The DML
-        # statement must be fully-partitionable. Specifically, the statement must be
-        # expressible as the union of many statements which each access only a single
-        # row of the table. - The statement is not applied atomically to all rows of the
-        # table. Rather, the statement is applied atomically to partitions of the table,
-        # in independent transactions. Secondary index rows are updated atomically with
-        # the base table rows. - Partitioned DML does not guarantee exactly-once
-        # execution semantics against a partition. The statement will be applied at
-        # least once to each partition. It is strongly recommended that the DML
-        # statement should be idempotent to avoid unexpected results. For instance, it
-        # is potentially dangerous to run a statement such as `UPDATE table SET column =
-        # column + 1` as it could be run multiple times against some rows. - The
-        # partitions are committed automatically - there is no support for Commit or
-        # Rollback. If the call returns an error, or if the client issuing the
-        # ExecuteSql call dies, it is possible that some rows had the statement executed
-        # on them successfully. It is also possible that statement was never executed
-        # against other rows. - Partitioned DML transactions may only contain the
-        # execution of a single DML statement via ExecuteSql or ExecuteStreamingSql. -
-        # If any error is encountered during the execution of the partitioned DML
-        # operation (for instance, a UNIQUE INDEX violation, division by zero, or a
-        # value that cannot be stored due to schema constraints), then the operation is
-        # stopped at that point and an error is returned. It is possible that at this
-        # point, some partitions have been committed (or even committed multiple times),
-        # and other partitions have not been run at all. Given the above, Partitioned
-        # DML is good fit for large, database-wide, operations that are idempotent, such
-        # as deleting old rows from a very large table.
+        # with too-old read timestamps fail with the error `FAILED_PRECONDITION`. You
+        # can configure and extend the `VERSION_RETENTION_PERIOD` of a database up to a
+        # period as long as one week, which allows Cloud Spanner to perform reads up to
+        # one week in the past. Partitioned DML transactions: Partitioned DML
+        # transactions are used to execute DML statements with a different execution
+        # strategy that provides different, and often better, scalability properties for
+        # large, table-wide operations than DML in a ReadWrite transaction. Smaller
+        # scoped statements, such as an OLTP workload, should prefer using ReadWrite
+        # transactions. Partitioned DML partitions the keyspace and runs the DML
+        # statement on each partition in separate, internal transactions. These
+        # transactions commit automatically when complete, and run independently from
+        # one another. To reduce lock contention, this execution strategy only acquires
+        # read locks on rows that match the WHERE clause of the statement. Additionally,
+        # the smaller per-partition transactions hold locks for less time. That said,
+        # Partitioned DML is not a drop-in replacement for standard DML used in
+        # ReadWrite transactions. - The DML statement must be fully-partitionable.
+        # Specifically, the statement must be expressible as the union of many
+        # statements which each access only a single row of the table. - The statement
+        # is not applied atomically to all rows of the table. Rather, the statement is
+        # applied atomically to partitions of the table, in independent transactions.
+        # Secondary index rows are updated atomically with the base table rows. -
+        # Partitioned DML does not guarantee exactly-once execution semantics against a
+        # partition. The statement will be applied at least once to each partition. It
+        # is strongly recommended that the DML statement should be idempotent to avoid
+        # unexpected results. For instance, it is potentially dangerous to run a
+        # statement such as `UPDATE table SET column = column + 1` as it could be run
+        # multiple times against some rows. - The partitions are committed automatically
+        # - there is no support for Commit or Rollback. If the call returns an error, or
+        # if the client issuing the ExecuteSql call dies, it is possible that some rows
+        # had the statement executed on them successfully. It is also possible that
+        # statement was never executed against other rows. - Partitioned DML
+        # transactions may only contain the execution of a single DML statement via
+        # ExecuteSql or ExecuteStreamingSql. - If any error is encountered during the
+        # execution of the partitioned DML operation (for instance, a UNIQUE INDEX
+        # violation, division by zero, or a value that cannot be stored due to schema
+        # constraints), then the operation is stopped at that point and an error is
+        # returned. It is possible that at this point, some partitions have been
+        # committed (or even committed multiple times), and other partitions have not
+        # been run at all. Given the above, Partitioned DML is good fit for large,
+        # database-wide, operations that are idempotent, such as deleting old rows from
+        # a very large table.
         # Corresponds to the JSON property `begin`
         # @return [Google::Apis::SpannerV1::TransactionOptions]
         attr_accessor :begin
@@ -4562,7 +4573,7 @@ module Google
         # count towards the one transaction limit). After the active transaction is
         # completed, the session can immediately be re-used for the next transaction. It
         # is not necessary to create a new session for each transaction. Transaction
-        # Modes: Cloud Spanner supports three transaction modes: 1. Locking read-write.
+        # modes: Cloud Spanner supports three transaction modes: 1. Locking read-write.
         # This type of transaction is the only way to write data into Cloud Spanner.
         # These transactions rely on pessimistic locking and, if necessary, two-phase
         # commit. Locking read-write transactions may abort, requiring the application
@@ -4578,9 +4589,9 @@ module Google
         # simpler semantics and are almost always faster. In particular, read-only
         # transactions do not take locks, so they do not conflict with read-write
         # transactions. As a consequence of not taking locks, they also do not abort, so
-        # retry loops are not needed. Transactions may only read/write data in a single
-        # database. They may, however, read/write data in different tables within that
-        # database. Locking Read-Write Transactions: Locking transactions may be used to
+        # retry loops are not needed. Transactions may only read-write data in a single
+        # database. They may, however, read-write data in different tables within that
+        # database. Locking read-write transactions: Locking transactions may be used to
         # atomically read-modify-write data anywhere in a database. This type of
         # transaction is externally consistent. Clients should attempt to minimize the
         # amount of time a transaction is active. Faster transactions commit with higher
@@ -4599,7 +4610,7 @@ module Google
         # Cloud Spanner makes no guarantees about how long the transaction's locks were
         # held for. It is an error to use Cloud Spanner locks for any sort of mutual
         # exclusion other than between Cloud Spanner transactions themselves. Retrying
-        # Aborted Transactions: When a transaction aborts, the application can choose to
+        # aborted transactions: When a transaction aborts, the application can choose to
         # retry the whole transaction again. To maximize the chances of successfully
         # 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
@@ -4608,14 +4619,14 @@ module Google
         # 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 time spent retrying. Idle Transactions:
+        # 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-
+        # 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.
@@ -4631,7 +4642,7 @@ module Google
         # 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,
+        # transactions can execute more quickly than strong or read-write transactions,
         # 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
@@ -4641,7 +4652,7 @@ module Google
         # 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
+        # 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
@@ -4655,7 +4666,7 @@ module Google
         # equivalent boundedly stale concurrency modes. On the other hand, boundedly
         # stale reads usually return fresher results. See TransactionOptions.ReadOnly.
         # read_timestamp and TransactionOptions.ReadOnly.exact_staleness. Bounded
-        # Staleness: Bounded staleness modes allow Cloud Spanner to pick the read
+        # staleness: Bounded staleness modes allow Cloud Spanner to pick the read
         # timestamp, subject to a user-provided staleness bound. Cloud Spanner chooses
         # the newest timestamp within the staleness bound that allows execution of the
         # reads at the closest available replica without blocking. All rows yielded are
@@ -4672,51 +4683,54 @@ module Google
         # timestamp negotiation requires up-front knowledge of which rows will be read,
         # it can only be used with single-use read-only transactions. See
         # TransactionOptions.ReadOnly.max_staleness and TransactionOptions.ReadOnly.
-        # min_read_timestamp. Old Read Timestamps and Garbage Collection: Cloud Spanner
+        # min_read_timestamp. Old read timestamps and garbage collection: Cloud Spanner
         # continuously garbage collects deleted and overwritten data in the background
         # to reclaim storage space. This process is known as "version GC". By default,
         # version GC reclaims versions after they are one hour old. Because of this,
         # Cloud Spanner cannot perform reads at read timestamps more than one hour in
         # the past. This restriction also applies to in-progress reads and/or SQL
         # queries whose timestamp become too old while executing. Reads and SQL queries
-        # with too-old read timestamps fail with the error `FAILED_PRECONDITION`.
-        # Partitioned DML Transactions: Partitioned DML transactions are used to execute
-        # DML statements with a different execution strategy that provides different,
-        # and often better, scalability properties for large, table-wide operations than
-        # DML in a ReadWrite transaction. Smaller scoped statements, such as an OLTP
-        # workload, should prefer using ReadWrite transactions. Partitioned DML
-        # partitions the keyspace and runs the DML statement on each partition in
-        # separate, internal transactions. These transactions commit automatically when
-        # complete, and run independently from one another. To reduce lock contention,
-        # this execution strategy only acquires read locks on rows that match the WHERE
-        # clause of the statement. Additionally, the smaller per-partition transactions
-        # hold locks for less time. That said, Partitioned DML is not a drop-in
-        # replacement for standard DML used in ReadWrite transactions. - The DML
-        # statement must be fully-partitionable. Specifically, the statement must be
-        # expressible as the union of many statements which each access only a single
-        # row of the table. - The statement is not applied atomically to all rows of the
-        # table. Rather, the statement is applied atomically to partitions of the table,
-        # in independent transactions. Secondary index rows are updated atomically with
-        # the base table rows. - Partitioned DML does not guarantee exactly-once
-        # execution semantics against a partition. The statement will be applied at
-        # least once to each partition. It is strongly recommended that the DML
-        # statement should be idempotent to avoid unexpected results. For instance, it
-        # is potentially dangerous to run a statement such as `UPDATE table SET column =
-        # column + 1` as it could be run multiple times against some rows. - The
-        # partitions are committed automatically - there is no support for Commit or
-        # Rollback. If the call returns an error, or if the client issuing the
-        # ExecuteSql call dies, it is possible that some rows had the statement executed
-        # on them successfully. It is also possible that statement was never executed
-        # against other rows. - Partitioned DML transactions may only contain the
-        # execution of a single DML statement via ExecuteSql or ExecuteStreamingSql. -
-        # If any error is encountered during the execution of the partitioned DML
-        # operation (for instance, a UNIQUE INDEX violation, division by zero, or a
-        # value that cannot be stored due to schema constraints), then the operation is
-        # stopped at that point and an error is returned. It is possible that at this
-        # point, some partitions have been committed (or even committed multiple times),
-        # and other partitions have not been run at all. Given the above, Partitioned
-        # DML is good fit for large, database-wide, operations that are idempotent, such
-        # as deleting old rows from a very large table.
+        # with too-old read timestamps fail with the error `FAILED_PRECONDITION`. You
+        # can configure and extend the `VERSION_RETENTION_PERIOD` of a database up to a
+        # period as long as one week, which allows Cloud Spanner to perform reads up to
+        # one week in the past. Partitioned DML transactions: Partitioned DML
+        # transactions are used to execute DML statements with a different execution
+        # strategy that provides different, and often better, scalability properties for
+        # large, table-wide operations than DML in a ReadWrite transaction. Smaller
+        # scoped statements, such as an OLTP workload, should prefer using ReadWrite
+        # transactions. Partitioned DML partitions the keyspace and runs the DML
+        # statement on each partition in separate, internal transactions. These
+        # transactions commit automatically when complete, and run independently from
+        # one another. To reduce lock contention, this execution strategy only acquires
+        # read locks on rows that match the WHERE clause of the statement. Additionally,
+        # the smaller per-partition transactions hold locks for less time. That said,
+        # Partitioned DML is not a drop-in replacement for standard DML used in
+        # ReadWrite transactions. - The DML statement must be fully-partitionable.
+        # Specifically, the statement must be expressible as the union of many
+        # statements which each access only a single row of the table. - The statement
+        # is not applied atomically to all rows of the table. Rather, the statement is
+        # applied atomically to partitions of the table, in independent transactions.
+        # Secondary index rows are updated atomically with the base table rows. -
+        # Partitioned DML does not guarantee exactly-once execution semantics against a
+        # partition. The statement will be applied at least once to each partition. It
+        # is strongly recommended that the DML statement should be idempotent to avoid
+        # unexpected results. For instance, it is potentially dangerous to run a
+        # statement such as `UPDATE table SET column = column + 1` as it could be run
+        # multiple times against some rows. - The partitions are committed automatically
+        # - there is no support for Commit or Rollback. If the call returns an error, or
+        # if the client issuing the ExecuteSql call dies, it is possible that some rows
+        # had the statement executed on them successfully. It is also possible that
+        # statement was never executed against other rows. - Partitioned DML
+        # transactions may only contain the execution of a single DML statement via
+        # ExecuteSql or ExecuteStreamingSql. - If any error is encountered during the
+        # execution of the partitioned DML operation (for instance, a UNIQUE INDEX
+        # violation, division by zero, or a value that cannot be stored due to schema
+        # constraints), then the operation is stopped at that point and an error is
+        # returned. It is possible that at this point, some partitions have been
+        # committed (or even committed multiple times), and other partitions have not
+        # been run at all. Given the above, Partitioned DML is good fit for large,
+        # database-wide, operations that are idempotent, such as deleting old rows from
+        # a very large table.
         # Corresponds to the JSON property `singleUse`
         # @return [Google::Apis::SpannerV1::TransactionOptions]
         attr_accessor :single_use

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.25.0"
+      GEM_VERSION = "0.26.0"
 
       # Version of the code generator used to generate this client
       GENERATOR_VERSION = "0.4.1"
 
       # Revision of the discovery document this client was generated from
-      REVISION = "20220310"
+      REVISION = "20220326"
     end
   end
 end

metadata

@@ -1,14 +1,14 @@
 --- !ruby/object:Gem::Specification
 name: google-apis-spanner_v1
 version: !ruby/object:Gem::Version
-  version: 0.25.0
+  version: 0.26.0
 platform: ruby
 authors:
 - Google LLC
 autorequire: 
 bindir: bin
 cert_chain: []
-date: 2022-03-21 00:00:00.000000000 Z
+date: 2022-04-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/main/generated/google-apis-spanner_v1/CHANGELOG.md
-  documentation_uri: https://googleapis.dev/ruby/google-apis-spanner_v1/v0.25.0
+  documentation_uri: https://googleapis.dev/ruby/google-apis-spanner_v1/v0.26.0
   source_code_uri: https://github.com/googleapis/google-api-ruby-client/tree/main/generated/google-apis-spanner_v1
 post_install_message: 
 rdoc_options: []