google-apis-spanner_v1 0.24.0 → 0.27.0

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

@@ -59,6 +59,15 @@ module Google
         # @return [String]
         attr_accessor :expire_time
       
+        # Output only. The max allowed expiration time of the backup, with microseconds
+        # granularity. A backup's expiration time can be configured in multiple APIs:
+        # CreateBackup, UpdateBackup, CopyBackup. When updating or copying an existing
+        # backup, the expiration time specified must be less than `Backup.
+        # max_expire_time`.
+        # Corresponds to the JSON property `maxExpireTime`
+        # @return [String]
+        attr_accessor :max_expire_time
+      
         # Output only for the CreateBackup operation. Required for the UpdateBackup
         # operation. A globally unique identifier for the backup which cannot be changed.
         # Values are of the form `projects//instances//backups/a-z*[a-z0-9]` The final
@@ -70,6 +79,16 @@ module Google
         # @return [String]
         attr_accessor :name
       
+        # Output only. The names of the destination backups being created by copying
+        # this source backup. The backup names are of the form `projects//instances//
+        # backups/`. Referencing backups may exist in different instances. The existence
+        # of any referencing backup prevents the backup from being deleted. When the
+        # copy operation is done (either successfully completed or cancelled or the
+        # destination backup is deleted), the reference to the backup is removed.
+        # Corresponds to the JSON property `referencingBackups`
+        # @return [Array<String>]
+        attr_accessor :referencing_backups
+      
         # Output only. The names of the restored databases that reference the backup.
         # The database names are of the form `projects//instances//databases/`.
         # Referencing databases may exist in different instances. The existence of any
@@ -108,7 +127,9 @@ module Google
           @database_dialect = args[:database_dialect] if args.key?(:database_dialect)
           @encryption_info = args[:encryption_info] if args.key?(:encryption_info)
           @expire_time = args[:expire_time] if args.key?(:expire_time)
+          @max_expire_time = args[:max_expire_time] if args.key?(:max_expire_time)
           @name = args[:name] if args.key?(:name)
+          @referencing_backups = args[:referencing_backups] if args.key?(:referencing_backups)
           @referencing_databases = args[:referencing_databases] if args.key?(:referencing_databases)
           @size_bytes = args[:size_bytes] if args.key?(:size_bytes)
           @state = args[:state] if args.key?(:state)
@@ -212,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
@@ -228,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
@@ -249,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
@@ -258,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.
@@ -281,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
@@ -291,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
@@ -305,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
@@ -322,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
@@ -524,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
@@ -540,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
@@ -561,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
@@ -570,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.
@@ -593,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
@@ -603,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
@@ -617,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
@@ -634,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
@@ -793,6 +820,125 @@ module Google
         end
       end
       
+      # Encryption configuration for the copied backup.
+      class CopyBackupEncryptionConfig
+        include Google::Apis::Core::Hashable
+      
+        # Required. The encryption type of the backup.
+        # Corresponds to the JSON property `encryptionType`
+        # @return [String]
+        attr_accessor :encryption_type
+      
+        # Optional. The Cloud KMS key that will be used to protect the backup. This
+        # field should be set only when encryption_type is `CUSTOMER_MANAGED_ENCRYPTION`.
+        # Values are of the form `projects//locations//keyRings//cryptoKeys/`.
+        # Corresponds to the JSON property `kmsKeyName`
+        # @return [String]
+        attr_accessor :kms_key_name
+      
+        def initialize(**args)
+           update!(**args)
+        end
+      
+        # Update properties of this object
+        def update!(**args)
+          @encryption_type = args[:encryption_type] if args.key?(:encryption_type)
+          @kms_key_name = args[:kms_key_name] if args.key?(:kms_key_name)
+        end
+      end
+      
+      # Metadata type for the operation returned by CopyBackup.
+      class CopyBackupMetadata
+        include Google::Apis::Core::Hashable
+      
+        # The time at which cancellation of CopyBackup operation was received.
+        # Operations.CancelOperation starts asynchronous cancellation on a long-running
+        # operation. The server makes a best effort to cancel the operation, but success
+        # is not guaranteed. Clients can use Operations.GetOperation or other methods to
+        # check whether the cancellation succeeded or whether the operation completed
+        # despite cancellation. On successful cancellation, the operation is not deleted;
+        # instead, it becomes an operation with an Operation.error value with a google.
+        # rpc.Status.code of 1, corresponding to `Code.CANCELLED`.
+        # Corresponds to the JSON property `cancelTime`
+        # @return [String]
+        attr_accessor :cancel_time
+      
+        # The name of the backup being created through the copy operation. Values are of
+        # the form `projects//instances//backups/`.
+        # Corresponds to the JSON property `name`
+        # @return [String]
+        attr_accessor :name
+      
+        # Encapsulates progress related information for a Cloud Spanner long running
+        # operation.
+        # Corresponds to the JSON property `progress`
+        # @return [Google::Apis::SpannerV1::OperationProgress]
+        attr_accessor :progress
+      
+        # The name of the source backup that is being copied. Values are of the form `
+        # projects//instances//backups/`.
+        # Corresponds to the JSON property `sourceBackup`
+        # @return [String]
+        attr_accessor :source_backup
+      
+        def initialize(**args)
+           update!(**args)
+        end
+      
+        # Update properties of this object
+        def update!(**args)
+          @cancel_time = args[:cancel_time] if args.key?(:cancel_time)
+          @name = args[:name] if args.key?(:name)
+          @progress = args[:progress] if args.key?(:progress)
+          @source_backup = args[:source_backup] if args.key?(:source_backup)
+        end
+      end
+      
+      # The request for CopyBackup.
+      class CopyBackupRequest
+        include Google::Apis::Core::Hashable
+      
+        # Required. The id of the backup copy. The `backup_id` appended to `parent`
+        # forms the full backup_uri of the form `projects//instances//backups/`.
+        # Corresponds to the JSON property `backupId`
+        # @return [String]
+        attr_accessor :backup_id
+      
+        # Encryption configuration for the copied backup.
+        # Corresponds to the JSON property `encryptionConfig`
+        # @return [Google::Apis::SpannerV1::CopyBackupEncryptionConfig]
+        attr_accessor :encryption_config
+      
+        # Required. The expiration time of the backup in microsecond granularity. The
+        # expiration time must be at least 6 hours and at most 366 days from the `
+        # create_time` of the source backup. Once the `expire_time` has passed, the
+        # backup is eligible to be automatically deleted by Cloud Spanner to free the
+        # resources used by the backup.
+        # Corresponds to the JSON property `expireTime`
+        # @return [String]
+        attr_accessor :expire_time
+      
+        # Required. The source backup to be copied. The source backup needs to be in
+        # READY state for it to be copied. Once CopyBackup is in progress, the source
+        # backup cannot be deleted or cleaned up on expiration until CopyBackup is
+        # finished. Values are of the form: `projects//instances//backups/`.
+        # Corresponds to the JSON property `sourceBackup`
+        # @return [String]
+        attr_accessor :source_backup
+      
+        def initialize(**args)
+           update!(**args)
+        end
+      
+        # Update properties of this object
+        def update!(**args)
+          @backup_id = args[:backup_id] if args.key?(:backup_id)
+          @encryption_config = args[:encryption_config] if args.key?(:encryption_config)
+          @expire_time = args[:expire_time] if args.key?(:expire_time)
+          @source_backup = args[:source_backup] if args.key?(:source_backup)
+        end
+      end
+      
       # Metadata type for the operation returned by CreateBackup.
       class CreateBackupMetadata
         include Google::Apis::Core::Hashable
@@ -1186,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
       
@@ -1657,6 +1802,11 @@ module Google
         # @return [String]
         attr_accessor :config
       
+        # Output only. The time at which the instance was created.
+        # Corresponds to the JSON property `createTime`
+        # @return [String]
+        attr_accessor :create_time
+      
         # Required. The descriptive name for this instance as it appears in UIs. Must be
         # unique per project and between 4 and 30 characters in length.
         # Corresponds to the JSON property `displayName`
@@ -1721,6 +1871,11 @@ module Google
         # @return [String]
         attr_accessor :state
       
+        # Output only. The time at which the instance was most recently updated.
+        # Corresponds to the JSON property `updateTime`
+        # @return [String]
+        attr_accessor :update_time
+      
         def initialize(**args)
            update!(**args)
         end
@@ -1728,6 +1883,7 @@ module Google
         # Update properties of this object
         def update!(**args)
           @config = args[:config] if args.key?(:config)
+          @create_time = args[:create_time] if args.key?(:create_time)
           @display_name = args[:display_name] if args.key?(:display_name)
           @endpoint_uris = args[:endpoint_uris] if args.key?(:endpoint_uris)
           @labels = args[:labels] if args.key?(:labels)
@@ -1735,6 +1891,7 @@ module Google
           @node_count = args[:node_count] if args.key?(:node_count)
           @processing_units = args[:processing_units] if args.key?(:processing_units)
           @state = args[:state] if args.key?(:state)
+          @update_time = args[:update_time] if args.key?(:update_time)
         end
       end
       
@@ -4044,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
@@ -4060,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
@@ -4081,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
@@ -4090,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.
@@ -4113,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
@@ -4123,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
@@ -4137,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
@@ -4154,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
       
@@ -4240,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
@@ -4256,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
@@ -4277,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
@@ -4286,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.
@@ -4309,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
@@ -4319,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
@@ -4333,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
@@ -4350,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
@@ -4410,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
@@ -4426,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
@@ -4447,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
@@ -4456,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.
@@ -4479,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
@@ -4489,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
@@ -4503,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
@@ -4520,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