google-apis-spanner_v1 0.16.0 → 0.20.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 6fbddcaa4658b3147d2258f83f732fdc5679b6d762e0c0aeeb120e6ad5f3726e
-  data.tar.gz: 3cd473218d291908672f0095738a11a7cd0ded8e15bc23edf465769340a9e710
+  metadata.gz: 83b75f47b3a786621e5272e72d004a614683f14f7f3ece3ef18421642876961f
+  data.tar.gz: c4ecd96e65cc2ba2e3df3b42479cb4d8bba1a1802995dcdc86c73dccb8eaf6c6
 SHA512:
-  metadata.gz: 22f24dbab2d23ac55ee2af9bf16a2f5e08ca79ce262a0d4debeddad921c6a7d9df01b621af41b15257761762e3e19eddc0be9844d002db75387761773099956d
-  data.tar.gz: 1c44606e7033bfb89ffa6651054412a552e4f05e3b4a66138135a19b32fc6c2d9149bc3ac519ca0b010607616fa08c88198774f96d9d9a31fd61f07a210fee60
+  metadata.gz: c1cd2ba8ba4efa565872de371a288d7c95d9bfab47766ddbcf9d768644e89dee289793e9250e32da585d1b173f1f7dc89d7dab92f1f73d55b4e0bec9bb5a4378
+  data.tar.gz: '0842b156e6d121d9157110952c085fc6ee8f4bf623d4a60c46564e3f52f4a84b743beb5d731e15772594e79c7aaeb97a8941f30f9abdf64fc4764f44953ad60b'

data/CHANGELOG.md

@@ -1,5 +1,22 @@
 # Release history for google-apis-spanner_v1
 
+### v0.20.0 (2021-10-23)
+
+* Regenerated from discovery document revision 20211021
+* Unspecified changes
+
+### v0.19.0 (2021-09-27)
+
+* Regenerated from discovery document revision 20210914
+
+### v0.18.0 (2021-08-30)
+
+* Regenerated from discovery document revision 20210825
+
+### v0.17.0 (2021-08-21)
+
+* Regenerated from discovery document revision 20210816
+
 ### v0.16.0 (2021-07-31)
 
 * Regenerated from discovery document revision 20210723

data/OVERVIEW.md

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

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

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

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

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

data/lib/google/apis/spanner_v1.rb

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

metadata

@@ -1,14 +1,14 @@
 --- !ruby/object:Gem::Specification
 name: google-apis-spanner_v1
 version: !ruby/object:Gem::Version
-  version: 0.16.0
+  version: 0.20.0
 platform: ruby
 authors:
 - Google LLC
 autorequire: 
 bindir: bin
 cert_chain: []
-date: 2021-08-02 00:00:00.000000000 Z
+date: 2021-10-27 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: google-apis-core
@@ -57,9 +57,9 @@ licenses:
 - Apache-2.0
 metadata:
   bug_tracker_uri: https://github.com/googleapis/google-api-ruby-client/issues
-  changelog_uri: https://github.com/googleapis/google-api-ruby-client/tree/master/generated/google-apis-spanner_v1/CHANGELOG.md
-  documentation_uri: https://googleapis.dev/ruby/google-apis-spanner_v1/v0.16.0
-  source_code_uri: https://github.com/googleapis/google-api-ruby-client/tree/master/generated/google-apis-spanner_v1
+  changelog_uri: https://github.com/googleapis/google-api-ruby-client/tree/main/generated/google-apis-spanner_v1/CHANGELOG.md
+  documentation_uri: https://googleapis.dev/ruby/google-apis-spanner_v1/v0.20.0
+  source_code_uri: https://github.com/googleapis/google-api-ruby-client/tree/main/generated/google-apis-spanner_v1
 post_install_message: 
 rdoc_options: []
 require_paths: