google-apis-spanner_v1 0.18.0 → 0.19.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 65f291bc4c13a877c513f8b6ac04a3649db401654adb0e09ae58552151b3014a
-  data.tar.gz: 25d78f30d9b22e2d035ee29638ed7e896cddc89b531af81f5422a336d0c5c720
+  metadata.gz: d2a066cde62010b9e3316bf3577a4833c6bc909f6ddeff9746e9bfa01415d2ec
+  data.tar.gz: 7921a7d949a8003b299858b58cbf4849a33adf8341e3dca210f9ea22ae4be94d
 SHA512:
-  metadata.gz: 69c490c9ee531e44481798c6f97a81063bfae060b3b30dcc42271f6f96ac364bc7dc03896145d4d9c1e51bcbc8da81be87cabc048911ec76d188b08d2e1f713b
-  data.tar.gz: 780daa7897e74b6d85e3a09a2c148c73f3241a620be09ee254331bdaf04fac84fe6f7c8f47a85149518ef811e62f72d76364a3955071f961cadb6e646fa3f108
+  metadata.gz: eb511303a6979888a2bc73ce005c59b6fc21ce0a7f19a2bbd04ccba3b74f607dc911152fcfa77123d0e2da6a388e371f277b3684368b0c8a99beaa8486d04725
+  data.tar.gz: 1c75f9196ced0547c7d475d24a8ade964acab87aa1e440a9de228bca9f15c6ab390b92a89698de09b4f207eb32f1ca6727a970336d521b471aae6e4f4f6bac53

data/CHANGELOG.md

@@ -1,5 +1,9 @@
 # Release history for google-apis-spanner_v1
 
+### v0.19.0 (2021-09-27)
+
+* Regenerated from discovery document revision 20210914
+
 ### v0.18.0 (2021-08-30)
 
 * Regenerated from discovery document revision 20210825

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

@@ -248,49 +248,50 @@ module Google
         # committing the retry, the client should execute the retry in the same session
         # as the original attempt. The original session's lock priority increases with
         # each consecutive abort, meaning that each attempt has a slightly better chance
-        # of success than the previous. Under some circumstances (e.g., many
+        # of success than the previous. Under some circumstances (for example, many
         # transactions attempting to modify the same row(s)), a transaction can abort
         # many times in a short period before successfully committing. Thus, it is not a
         # good idea to cap the number of retries a transaction can attempt; instead, it
-        # is better to limit the total amount of wall time spent retrying. Idle
-        # Transactions: A transaction is considered idle if it has no outstanding reads
-        # or SQL queries and has not started a read or SQL query within the last 10
-        # seconds. Idle transactions can be aborted by Cloud Spanner so that they don't
-        # hold on to locks indefinitely. In that case, the commit will fail with error `
-        # ABORTED`. If this behavior is undesirable, periodically executing a simple SQL
-        # query in the transaction (e.g., `SELECT 1`) prevents the transaction from
-        # becoming idle. Snapshot Read-Only Transactions: Snapshot read-only
-        # transactions provides a simpler method than locking read-write transactions
-        # for doing several consistent reads. However, this type of transaction does not
-        # support writes. Snapshot transactions do not take locks. Instead, they work by
-        # choosing a Cloud Spanner timestamp, then executing all reads at that timestamp.
-        # Since they do not acquire locks, they do not block concurrent read-write
-        # transactions. Unlike locking read-write transactions, snapshot read-only
-        # transactions never abort. They can fail if the chosen read timestamp is
-        # garbage collected; however, the default garbage collection policy is generous
-        # enough that most applications do not need to worry about this in practice.
-        # Snapshot read-only transactions do not need to call Commit or Rollback (and in
-        # fact are not permitted to do so). To execute a snapshot transaction, the
-        # client specifies a timestamp bound, which tells Cloud Spanner how to choose a
-        # read timestamp. The types of timestamp bound are: - Strong (the default). -
-        # Bounded staleness. - Exact staleness. If the Cloud Spanner database to be read
-        # is geographically distributed, stale read-only transactions can execute more
-        # quickly than strong or read-write transaction, because they are able to
-        # execute far from the leader replica. Each type of timestamp bound is discussed
-        # in detail below. Strong: Strong reads are guaranteed to see the effects of all
-        # transactions that have committed before the start of the read. Furthermore,
-        # all rows yielded by a single read are consistent with each other -- if any
-        # part of the read observes a transaction, all parts of the read see the
-        # transaction. Strong reads are not repeatable: two consecutive strong read-only
-        # transactions might return inconsistent results if there are concurrent writes.
-        # If consistency across reads is required, the reads should be executed within a
-        # transaction or at an exact read timestamp. See TransactionOptions.ReadOnly.
-        # strong. Exact Staleness: These timestamp bounds execute reads at a user-
-        # specified timestamp. Reads at a timestamp are guaranteed to see a consistent
-        # prefix of the global transaction history: they observe modifications done by
-        # all transactions with a commit timestamp <= the read timestamp, and observe
-        # none of the modifications done by transactions with a larger commit timestamp.
-        # They will block until all conflicting transactions that may be assigned commit
+        # is better to limit the total amount of time spent retrying. Idle Transactions:
+        # A transaction is considered idle if it has no outstanding reads or SQL queries
+        # and has not started a read or SQL query within the last 10 seconds. Idle
+        # transactions can be aborted by Cloud Spanner so that they don't hold on to
+        # locks indefinitely. If an idle transaction is aborted, the commit will fail
+        # with error `ABORTED`. If this behavior is undesirable, periodically executing
+        # a simple SQL query in the transaction (for example, `SELECT 1`) prevents the
+        # transaction from becoming idle. Snapshot Read-Only Transactions: Snapshot read-
+        # only transactions provides a simpler method than locking read-write
+        # transactions for doing several consistent reads. However, this type of
+        # transaction does not support writes. Snapshot transactions do not take locks.
+        # Instead, they work by choosing a Cloud Spanner timestamp, then executing all
+        # reads at that timestamp. Since they do not acquire locks, they do not block
+        # concurrent read-write transactions. Unlike locking read-write transactions,
+        # snapshot read-only transactions never abort. They can fail if the chosen read
+        # timestamp is garbage collected; however, the default garbage collection policy
+        # is generous enough that most applications do not need to worry about this in
+        # practice. Snapshot read-only transactions do not need to call Commit or
+        # Rollback (and in fact are not permitted to do so). To execute a snapshot
+        # transaction, the client specifies a timestamp bound, which tells Cloud Spanner
+        # how to choose a read timestamp. The types of timestamp bound are: - Strong (
+        # the default). - Bounded staleness. - Exact staleness. If the Cloud Spanner
+        # database to be read is geographically distributed, stale read-only
+        # transactions can execute more quickly than strong or read-write transaction,
+        # because they are able to execute far from the leader replica. Each type of
+        # timestamp bound is discussed in detail below. Strong: Strong reads are
+        # guaranteed to see the effects of all transactions that have committed before
+        # the start of the read. Furthermore, all rows yielded by a single read are
+        # consistent with each other -- if any part of the read observes a transaction,
+        # all parts of the read see the transaction. Strong reads are not repeatable:
+        # two consecutive strong read-only transactions might return inconsistent
+        # results if there are concurrent writes. If consistency across reads is
+        # required, the reads should be executed within a transaction or at an exact
+        # read timestamp. See TransactionOptions.ReadOnly.strong. Exact Staleness: These
+        # timestamp bounds execute reads at a user-specified timestamp. Reads at a
+        # timestamp are guaranteed to see a consistent prefix of the global transaction
+        # history: they observe modifications done by all transactions with a commit
+        # timestamp less than or equal to the read timestamp, and observe none of the
+        # modifications done by transactions with a larger commit timestamp. They will
+        # block until all conflicting transactions that may be assigned commit
         # timestamps <= the read timestamp have finished. The timestamp can either be
         # expressed as an absolute Cloud Spanner commit timestamp or a staleness
         # relative to the current time. These modes do not require a "negotiation phase"
@@ -559,49 +560,50 @@ module Google
         # committing the retry, the client should execute the retry in the same session
         # as the original attempt. The original session's lock priority increases with
         # each consecutive abort, meaning that each attempt has a slightly better chance
-        # of success than the previous. Under some circumstances (e.g., many
+        # of success than the previous. Under some circumstances (for example, many
         # transactions attempting to modify the same row(s)), a transaction can abort
         # many times in a short period before successfully committing. Thus, it is not a
         # good idea to cap the number of retries a transaction can attempt; instead, it
-        # is better to limit the total amount of wall time spent retrying. Idle
-        # Transactions: A transaction is considered idle if it has no outstanding reads
-        # or SQL queries and has not started a read or SQL query within the last 10
-        # seconds. Idle transactions can be aborted by Cloud Spanner so that they don't
-        # hold on to locks indefinitely. In that case, the commit will fail with error `
-        # ABORTED`. If this behavior is undesirable, periodically executing a simple SQL
-        # query in the transaction (e.g., `SELECT 1`) prevents the transaction from
-        # becoming idle. Snapshot Read-Only Transactions: Snapshot read-only
-        # transactions provides a simpler method than locking read-write transactions
-        # for doing several consistent reads. However, this type of transaction does not
-        # support writes. Snapshot transactions do not take locks. Instead, they work by
-        # choosing a Cloud Spanner timestamp, then executing all reads at that timestamp.
-        # Since they do not acquire locks, they do not block concurrent read-write
-        # transactions. Unlike locking read-write transactions, snapshot read-only
-        # transactions never abort. They can fail if the chosen read timestamp is
-        # garbage collected; however, the default garbage collection policy is generous
-        # enough that most applications do not need to worry about this in practice.
-        # Snapshot read-only transactions do not need to call Commit or Rollback (and in
-        # fact are not permitted to do so). To execute a snapshot transaction, the
-        # client specifies a timestamp bound, which tells Cloud Spanner how to choose a
-        # read timestamp. The types of timestamp bound are: - Strong (the default). -
-        # Bounded staleness. - Exact staleness. If the Cloud Spanner database to be read
-        # is geographically distributed, stale read-only transactions can execute more
-        # quickly than strong or read-write transaction, because they are able to
-        # execute far from the leader replica. Each type of timestamp bound is discussed
-        # in detail below. Strong: Strong reads are guaranteed to see the effects of all
-        # transactions that have committed before the start of the read. Furthermore,
-        # all rows yielded by a single read are consistent with each other -- if any
-        # part of the read observes a transaction, all parts of the read see the
-        # transaction. Strong reads are not repeatable: two consecutive strong read-only
-        # transactions might return inconsistent results if there are concurrent writes.
-        # If consistency across reads is required, the reads should be executed within a
-        # transaction or at an exact read timestamp. See TransactionOptions.ReadOnly.
-        # strong. Exact Staleness: These timestamp bounds execute reads at a user-
-        # specified timestamp. Reads at a timestamp are guaranteed to see a consistent
-        # prefix of the global transaction history: they observe modifications done by
-        # all transactions with a commit timestamp <= the read timestamp, and observe
-        # none of the modifications done by transactions with a larger commit timestamp.
-        # They will block until all conflicting transactions that may be assigned commit
+        # is better to limit the total amount of time spent retrying. Idle Transactions:
+        # A transaction is considered idle if it has no outstanding reads or SQL queries
+        # and has not started a read or SQL query within the last 10 seconds. Idle
+        # transactions can be aborted by Cloud Spanner so that they don't hold on to
+        # locks indefinitely. If an idle transaction is aborted, the commit will fail
+        # with error `ABORTED`. If this behavior is undesirable, periodically executing
+        # a simple SQL query in the transaction (for example, `SELECT 1`) prevents the
+        # transaction from becoming idle. Snapshot Read-Only Transactions: Snapshot read-
+        # only transactions provides a simpler method than locking read-write
+        # transactions for doing several consistent reads. However, this type of
+        # transaction does not support writes. Snapshot transactions do not take locks.
+        # Instead, they work by choosing a Cloud Spanner timestamp, then executing all
+        # reads at that timestamp. Since they do not acquire locks, they do not block
+        # concurrent read-write transactions. Unlike locking read-write transactions,
+        # snapshot read-only transactions never abort. They can fail if the chosen read
+        # timestamp is garbage collected; however, the default garbage collection policy
+        # is generous enough that most applications do not need to worry about this in
+        # practice. Snapshot read-only transactions do not need to call Commit or
+        # Rollback (and in fact are not permitted to do so). To execute a snapshot
+        # transaction, the client specifies a timestamp bound, which tells Cloud Spanner
+        # how to choose a read timestamp. The types of timestamp bound are: - Strong (
+        # the default). - Bounded staleness. - Exact staleness. If the Cloud Spanner
+        # database to be read is geographically distributed, stale read-only
+        # transactions can execute more quickly than strong or read-write transaction,
+        # because they are able to execute far from the leader replica. Each type of
+        # timestamp bound is discussed in detail below. Strong: Strong reads are
+        # guaranteed to see the effects of all transactions that have committed before
+        # the start of the read. Furthermore, all rows yielded by a single read are
+        # consistent with each other -- if any part of the read observes a transaction,
+        # all parts of the read see the transaction. Strong reads are not repeatable:
+        # two consecutive strong read-only transactions might return inconsistent
+        # results if there are concurrent writes. If consistency across reads is
+        # required, the reads should be executed within a transaction or at an exact
+        # read timestamp. See TransactionOptions.ReadOnly.strong. Exact Staleness: These
+        # timestamp bounds execute reads at a user-specified timestamp. Reads at a
+        # timestamp are guaranteed to see a consistent prefix of the global transaction
+        # history: they observe modifications done by all transactions with a commit
+        # timestamp less than or equal to the read timestamp, and observe none of the
+        # modifications done by transactions with a larger commit timestamp. They will
+        # block until all conflicting transactions that may be assigned commit
         # timestamps <= the read timestamp have finished. The timestamp can either be
         # expressed as an absolute Cloud Spanner commit timestamp or a staleness
         # relative to the current time. These modes do not require a "negotiation phase"
@@ -4057,49 +4059,50 @@ module Google
       # committing the retry, the client should execute the retry in the same session
       # as the original attempt. The original session's lock priority increases with
       # each consecutive abort, meaning that each attempt has a slightly better chance
-      # of success than the previous. Under some circumstances (e.g., many
+      # of success than the previous. Under some circumstances (for example, many
       # transactions attempting to modify the same row(s)), a transaction can abort
       # many times in a short period before successfully committing. Thus, it is not a
       # good idea to cap the number of retries a transaction can attempt; instead, it
-      # is better to limit the total amount of wall time spent retrying. Idle
-      # Transactions: A transaction is considered idle if it has no outstanding reads
-      # or SQL queries and has not started a read or SQL query within the last 10
-      # seconds. Idle transactions can be aborted by Cloud Spanner so that they don't
-      # hold on to locks indefinitely. In that case, the commit will fail with error `
-      # ABORTED`. If this behavior is undesirable, periodically executing a simple SQL
-      # query in the transaction (e.g., `SELECT 1`) prevents the transaction from
-      # becoming idle. Snapshot Read-Only Transactions: Snapshot read-only
-      # transactions provides a simpler method than locking read-write transactions
-      # for doing several consistent reads. However, this type of transaction does not
-      # support writes. Snapshot transactions do not take locks. Instead, they work by
-      # choosing a Cloud Spanner timestamp, then executing all reads at that timestamp.
-      # Since they do not acquire locks, they do not block concurrent read-write
-      # transactions. Unlike locking read-write transactions, snapshot read-only
-      # transactions never abort. They can fail if the chosen read timestamp is
-      # garbage collected; however, the default garbage collection policy is generous
-      # enough that most applications do not need to worry about this in practice.
-      # Snapshot read-only transactions do not need to call Commit or Rollback (and in
-      # fact are not permitted to do so). To execute a snapshot transaction, the
-      # client specifies a timestamp bound, which tells Cloud Spanner how to choose a
-      # read timestamp. The types of timestamp bound are: - Strong (the default). -
-      # Bounded staleness. - Exact staleness. If the Cloud Spanner database to be read
-      # is geographically distributed, stale read-only transactions can execute more
-      # quickly than strong or read-write transaction, because they are able to
-      # execute far from the leader replica. Each type of timestamp bound is discussed
-      # in detail below. Strong: Strong reads are guaranteed to see the effects of all
-      # transactions that have committed before the start of the read. Furthermore,
-      # all rows yielded by a single read are consistent with each other -- if any
-      # part of the read observes a transaction, all parts of the read see the
-      # transaction. Strong reads are not repeatable: two consecutive strong read-only
-      # transactions might return inconsistent results if there are concurrent writes.
-      # If consistency across reads is required, the reads should be executed within a
-      # transaction or at an exact read timestamp. See TransactionOptions.ReadOnly.
-      # strong. Exact Staleness: These timestamp bounds execute reads at a user-
-      # specified timestamp. Reads at a timestamp are guaranteed to see a consistent
-      # prefix of the global transaction history: they observe modifications done by
-      # all transactions with a commit timestamp <= the read timestamp, and observe
-      # none of the modifications done by transactions with a larger commit timestamp.
-      # They will block until all conflicting transactions that may be assigned commit
+      # is better to limit the total amount of time spent retrying. Idle Transactions:
+      # A transaction is considered idle if it has no outstanding reads or SQL queries
+      # and has not started a read or SQL query within the last 10 seconds. Idle
+      # transactions can be aborted by Cloud Spanner so that they don't hold on to
+      # locks indefinitely. If an idle transaction is aborted, the commit will fail
+      # with error `ABORTED`. If this behavior is undesirable, periodically executing
+      # a simple SQL query in the transaction (for example, `SELECT 1`) prevents the
+      # transaction from becoming idle. Snapshot Read-Only Transactions: Snapshot read-
+      # only transactions provides a simpler method than locking read-write
+      # transactions for doing several consistent reads. However, this type of
+      # transaction does not support writes. Snapshot transactions do not take locks.
+      # Instead, they work by choosing a Cloud Spanner timestamp, then executing all
+      # reads at that timestamp. Since they do not acquire locks, they do not block
+      # concurrent read-write transactions. Unlike locking read-write transactions,
+      # snapshot read-only transactions never abort. They can fail if the chosen read
+      # timestamp is garbage collected; however, the default garbage collection policy
+      # is generous enough that most applications do not need to worry about this in
+      # practice. Snapshot read-only transactions do not need to call Commit or
+      # Rollback (and in fact are not permitted to do so). To execute a snapshot
+      # transaction, the client specifies a timestamp bound, which tells Cloud Spanner
+      # how to choose a read timestamp. The types of timestamp bound are: - Strong (
+      # the default). - Bounded staleness. - Exact staleness. If the Cloud Spanner
+      # database to be read is geographically distributed, stale read-only
+      # transactions can execute more quickly than strong or read-write transaction,
+      # because they are able to execute far from the leader replica. Each type of
+      # timestamp bound is discussed in detail below. Strong: Strong reads are
+      # guaranteed to see the effects of all transactions that have committed before
+      # the start of the read. Furthermore, all rows yielded by a single read are
+      # consistent with each other -- if any part of the read observes a transaction,
+      # all parts of the read see the transaction. Strong reads are not repeatable:
+      # two consecutive strong read-only transactions might return inconsistent
+      # results if there are concurrent writes. If consistency across reads is
+      # required, the reads should be executed within a transaction or at an exact
+      # read timestamp. See TransactionOptions.ReadOnly.strong. Exact Staleness: These
+      # timestamp bounds execute reads at a user-specified timestamp. Reads at a
+      # timestamp are guaranteed to see a consistent prefix of the global transaction
+      # history: they observe modifications done by all transactions with a commit
+      # timestamp less than or equal to the read timestamp, and observe none of the
+      # modifications done by transactions with a larger commit timestamp. They will
+      # block until all conflicting transactions that may be assigned commit
       # timestamps <= the read timestamp have finished. The timestamp can either be
       # expressed as an absolute Cloud Spanner commit timestamp or a staleness
       # relative to the current time. These modes do not require a "negotiation phase"
@@ -4252,49 +4255,50 @@ module Google
         # committing the retry, the client should execute the retry in the same session
         # as the original attempt. The original session's lock priority increases with
         # each consecutive abort, meaning that each attempt has a slightly better chance
-        # of success than the previous. Under some circumstances (e.g., many
+        # of success than the previous. Under some circumstances (for example, many
         # transactions attempting to modify the same row(s)), a transaction can abort
         # many times in a short period before successfully committing. Thus, it is not a
         # good idea to cap the number of retries a transaction can attempt; instead, it
-        # is better to limit the total amount of wall time spent retrying. Idle
-        # Transactions: A transaction is considered idle if it has no outstanding reads
-        # or SQL queries and has not started a read or SQL query within the last 10
-        # seconds. Idle transactions can be aborted by Cloud Spanner so that they don't
-        # hold on to locks indefinitely. In that case, the commit will fail with error `
-        # ABORTED`. If this behavior is undesirable, periodically executing a simple SQL
-        # query in the transaction (e.g., `SELECT 1`) prevents the transaction from
-        # becoming idle. Snapshot Read-Only Transactions: Snapshot read-only
-        # transactions provides a simpler method than locking read-write transactions
-        # for doing several consistent reads. However, this type of transaction does not
-        # support writes. Snapshot transactions do not take locks. Instead, they work by
-        # choosing a Cloud Spanner timestamp, then executing all reads at that timestamp.
-        # Since they do not acquire locks, they do not block concurrent read-write
-        # transactions. Unlike locking read-write transactions, snapshot read-only
-        # transactions never abort. They can fail if the chosen read timestamp is
-        # garbage collected; however, the default garbage collection policy is generous
-        # enough that most applications do not need to worry about this in practice.
-        # Snapshot read-only transactions do not need to call Commit or Rollback (and in
-        # fact are not permitted to do so). To execute a snapshot transaction, the
-        # client specifies a timestamp bound, which tells Cloud Spanner how to choose a
-        # read timestamp. The types of timestamp bound are: - Strong (the default). -
-        # Bounded staleness. - Exact staleness. If the Cloud Spanner database to be read
-        # is geographically distributed, stale read-only transactions can execute more
-        # quickly than strong or read-write transaction, because they are able to
-        # execute far from the leader replica. Each type of timestamp bound is discussed
-        # in detail below. Strong: Strong reads are guaranteed to see the effects of all
-        # transactions that have committed before the start of the read. Furthermore,
-        # all rows yielded by a single read are consistent with each other -- if any
-        # part of the read observes a transaction, all parts of the read see the
-        # transaction. Strong reads are not repeatable: two consecutive strong read-only
-        # transactions might return inconsistent results if there are concurrent writes.
-        # If consistency across reads is required, the reads should be executed within a
-        # transaction or at an exact read timestamp. See TransactionOptions.ReadOnly.
-        # strong. Exact Staleness: These timestamp bounds execute reads at a user-
-        # specified timestamp. Reads at a timestamp are guaranteed to see a consistent
-        # prefix of the global transaction history: they observe modifications done by
-        # all transactions with a commit timestamp <= the read timestamp, and observe
-        # none of the modifications done by transactions with a larger commit timestamp.
-        # They will block until all conflicting transactions that may be assigned commit
+        # is better to limit the total amount of time spent retrying. Idle Transactions:
+        # A transaction is considered idle if it has no outstanding reads or SQL queries
+        # and has not started a read or SQL query within the last 10 seconds. Idle
+        # transactions can be aborted by Cloud Spanner so that they don't hold on to
+        # locks indefinitely. If an idle transaction is aborted, the commit will fail
+        # with error `ABORTED`. If this behavior is undesirable, periodically executing
+        # a simple SQL query in the transaction (for example, `SELECT 1`) prevents the
+        # transaction from becoming idle. Snapshot Read-Only Transactions: Snapshot read-
+        # only transactions provides a simpler method than locking read-write
+        # transactions for doing several consistent reads. However, this type of
+        # transaction does not support writes. Snapshot transactions do not take locks.
+        # Instead, they work by choosing a Cloud Spanner timestamp, then executing all
+        # reads at that timestamp. Since they do not acquire locks, they do not block
+        # concurrent read-write transactions. Unlike locking read-write transactions,
+        # snapshot read-only transactions never abort. They can fail if the chosen read
+        # timestamp is garbage collected; however, the default garbage collection policy
+        # is generous enough that most applications do not need to worry about this in
+        # practice. Snapshot read-only transactions do not need to call Commit or
+        # Rollback (and in fact are not permitted to do so). To execute a snapshot
+        # transaction, the client specifies a timestamp bound, which tells Cloud Spanner
+        # how to choose a read timestamp. The types of timestamp bound are: - Strong (
+        # the default). - Bounded staleness. - Exact staleness. If the Cloud Spanner
+        # database to be read is geographically distributed, stale read-only
+        # transactions can execute more quickly than strong or read-write transaction,
+        # because they are able to execute far from the leader replica. Each type of
+        # timestamp bound is discussed in detail below. Strong: Strong reads are
+        # guaranteed to see the effects of all transactions that have committed before
+        # the start of the read. Furthermore, all rows yielded by a single read are
+        # consistent with each other -- if any part of the read observes a transaction,
+        # all parts of the read see the transaction. Strong reads are not repeatable:
+        # two consecutive strong read-only transactions might return inconsistent
+        # results if there are concurrent writes. If consistency across reads is
+        # required, the reads should be executed within a transaction or at an exact
+        # read timestamp. See TransactionOptions.ReadOnly.strong. Exact Staleness: These
+        # timestamp bounds execute reads at a user-specified timestamp. Reads at a
+        # timestamp are guaranteed to see a consistent prefix of the global transaction
+        # history: they observe modifications done by all transactions with a commit
+        # timestamp less than or equal to the read timestamp, and observe none of the
+        # modifications done by transactions with a larger commit timestamp. They will
+        # block until all conflicting transactions that may be assigned commit
         # timestamps <= the read timestamp have finished. The timestamp can either be
         # expressed as an absolute Cloud Spanner commit timestamp or a staleness
         # relative to the current time. These modes do not require a "negotiation phase"
@@ -4421,49 +4425,50 @@ module Google
         # committing the retry, the client should execute the retry in the same session
         # as the original attempt. The original session's lock priority increases with
         # each consecutive abort, meaning that each attempt has a slightly better chance
-        # of success than the previous. Under some circumstances (e.g., many
+        # of success than the previous. Under some circumstances (for example, many
         # transactions attempting to modify the same row(s)), a transaction can abort
         # many times in a short period before successfully committing. Thus, it is not a
         # good idea to cap the number of retries a transaction can attempt; instead, it
-        # is better to limit the total amount of wall time spent retrying. Idle
-        # Transactions: A transaction is considered idle if it has no outstanding reads
-        # or SQL queries and has not started a read or SQL query within the last 10
-        # seconds. Idle transactions can be aborted by Cloud Spanner so that they don't
-        # hold on to locks indefinitely. In that case, the commit will fail with error `
-        # ABORTED`. If this behavior is undesirable, periodically executing a simple SQL
-        # query in the transaction (e.g., `SELECT 1`) prevents the transaction from
-        # becoming idle. Snapshot Read-Only Transactions: Snapshot read-only
-        # transactions provides a simpler method than locking read-write transactions
-        # for doing several consistent reads. However, this type of transaction does not
-        # support writes. Snapshot transactions do not take locks. Instead, they work by
-        # choosing a Cloud Spanner timestamp, then executing all reads at that timestamp.
-        # Since they do not acquire locks, they do not block concurrent read-write
-        # transactions. Unlike locking read-write transactions, snapshot read-only
-        # transactions never abort. They can fail if the chosen read timestamp is
-        # garbage collected; however, the default garbage collection policy is generous
-        # enough that most applications do not need to worry about this in practice.
-        # Snapshot read-only transactions do not need to call Commit or Rollback (and in
-        # fact are not permitted to do so). To execute a snapshot transaction, the
-        # client specifies a timestamp bound, which tells Cloud Spanner how to choose a
-        # read timestamp. The types of timestamp bound are: - Strong (the default). -
-        # Bounded staleness. - Exact staleness. If the Cloud Spanner database to be read
-        # is geographically distributed, stale read-only transactions can execute more
-        # quickly than strong or read-write transaction, because they are able to
-        # execute far from the leader replica. Each type of timestamp bound is discussed
-        # in detail below. Strong: Strong reads are guaranteed to see the effects of all
-        # transactions that have committed before the start of the read. Furthermore,
-        # all rows yielded by a single read are consistent with each other -- if any
-        # part of the read observes a transaction, all parts of the read see the
-        # transaction. Strong reads are not repeatable: two consecutive strong read-only
-        # transactions might return inconsistent results if there are concurrent writes.
-        # If consistency across reads is required, the reads should be executed within a
-        # transaction or at an exact read timestamp. See TransactionOptions.ReadOnly.
-        # strong. Exact Staleness: These timestamp bounds execute reads at a user-
-        # specified timestamp. Reads at a timestamp are guaranteed to see a consistent
-        # prefix of the global transaction history: they observe modifications done by
-        # all transactions with a commit timestamp <= the read timestamp, and observe
-        # none of the modifications done by transactions with a larger commit timestamp.
-        # They will block until all conflicting transactions that may be assigned commit
+        # is better to limit the total amount of time spent retrying. Idle Transactions:
+        # A transaction is considered idle if it has no outstanding reads or SQL queries
+        # and has not started a read or SQL query within the last 10 seconds. Idle
+        # transactions can be aborted by Cloud Spanner so that they don't hold on to
+        # locks indefinitely. If an idle transaction is aborted, the commit will fail
+        # with error `ABORTED`. If this behavior is undesirable, periodically executing
+        # a simple SQL query in the transaction (for example, `SELECT 1`) prevents the
+        # transaction from becoming idle. Snapshot Read-Only Transactions: Snapshot read-
+        # only transactions provides a simpler method than locking read-write
+        # transactions for doing several consistent reads. However, this type of
+        # transaction does not support writes. Snapshot transactions do not take locks.
+        # Instead, they work by choosing a Cloud Spanner timestamp, then executing all
+        # reads at that timestamp. Since they do not acquire locks, they do not block
+        # concurrent read-write transactions. Unlike locking read-write transactions,
+        # snapshot read-only transactions never abort. They can fail if the chosen read
+        # timestamp is garbage collected; however, the default garbage collection policy
+        # is generous enough that most applications do not need to worry about this in
+        # practice. Snapshot read-only transactions do not need to call Commit or
+        # Rollback (and in fact are not permitted to do so). To execute a snapshot
+        # transaction, the client specifies a timestamp bound, which tells Cloud Spanner
+        # how to choose a read timestamp. The types of timestamp bound are: - Strong (
+        # the default). - Bounded staleness. - Exact staleness. If the Cloud Spanner
+        # database to be read is geographically distributed, stale read-only
+        # transactions can execute more quickly than strong or read-write transaction,
+        # because they are able to execute far from the leader replica. Each type of
+        # timestamp bound is discussed in detail below. Strong: Strong reads are
+        # guaranteed to see the effects of all transactions that have committed before
+        # the start of the read. Furthermore, all rows yielded by a single read are
+        # consistent with each other -- if any part of the read observes a transaction,
+        # all parts of the read see the transaction. Strong reads are not repeatable:
+        # two consecutive strong read-only transactions might return inconsistent
+        # results if there are concurrent writes. If consistency across reads is
+        # required, the reads should be executed within a transaction or at an exact
+        # read timestamp. See TransactionOptions.ReadOnly.strong. Exact Staleness: These
+        # timestamp bounds execute reads at a user-specified timestamp. Reads at a
+        # timestamp are guaranteed to see a consistent prefix of the global transaction
+        # history: they observe modifications done by all transactions with a commit
+        # timestamp less than or equal to the read timestamp, and observe none of the
+        # modifications done by transactions with a larger commit timestamp. They will
+        # block until all conflicting transactions that may be assigned commit
         # timestamps <= the read timestamp have finished. The timestamp can either be
         # expressed as an absolute Cloud Spanner commit timestamp or a staleness
         # relative to the current time. These modes do not require a "negotiation phase"

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

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

metadata

@@ -1,14 +1,14 @@
 --- !ruby/object:Gem::Specification
 name: google-apis-spanner_v1
 version: !ruby/object:Gem::Version
-  version: 0.18.0
+  version: 0.19.0
 platform: ruby
 authors:
 - Google LLC
 autorequire: 
 bindir: bin
 cert_chain: []
-date: 2021-09-06 00:00:00.000000000 Z
+date: 2021-10-04 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: google-apis-core
@@ -58,7 +58,7 @@ licenses:
 metadata:
   bug_tracker_uri: https://github.com/googleapis/google-api-ruby-client/issues
   changelog_uri: https://github.com/googleapis/google-api-ruby-client/tree/master/generated/google-apis-spanner_v1/CHANGELOG.md
-  documentation_uri: https://googleapis.dev/ruby/google-apis-spanner_v1/v0.18.0
+  documentation_uri: https://googleapis.dev/ruby/google-apis-spanner_v1/v0.19.0
   source_code_uri: https://github.com/googleapis/google-api-ruby-client/tree/master/generated/google-apis-spanner_v1
 post_install_message: 
 rdoc_options: []