chore: regens API reference docs (#889)
diff --git a/docs/dyn/firestore_v1beta1.projects.databases.html b/docs/dyn/firestore_v1beta1.projects.databases.html
index 399610e..caf387f 100644
--- a/docs/dyn/firestore_v1beta1.projects.databases.html
+++ b/docs/dyn/firestore_v1beta1.projects.databases.html
@@ -85,14 +85,14 @@
<p class="firstline">Returns the indexes Resource.</p>
<p class="toc_element">
- <code><a href="#exportDocuments">exportDocuments(name, body, x__xgafv=None)</a></code></p>
+ <code><a href="#exportDocuments">exportDocuments(name, body=None, x__xgafv=None)</a></code></p>
<p class="firstline">Exports a copy of all or a subset of documents from Google Cloud Firestore</p>
<p class="toc_element">
- <code><a href="#importDocuments">importDocuments(name, body, x__xgafv=None)</a></code></p>
+ <code><a href="#importDocuments">importDocuments(name, body=None, x__xgafv=None)</a></code></p>
<p class="firstline">Imports documents into Google Cloud Firestore. Existing documents with the</p>
<h3>Method Details</h3>
<div class="method">
- <code class="details" id="exportDocuments">exportDocuments(name, body, x__xgafv=None)</code>
+ <code class="details" id="exportDocuments">exportDocuments(name, body=None, x__xgafv=None)</code>
<pre>Exports a copy of all or a subset of documents from Google Cloud Firestore
to another storage system, such as Google Cloud Storage. Recent updates to
documents may not be reflected in the export. The export occurs in the
@@ -105,7 +105,7 @@
Args:
name: string, Database to export. Should be of the form:
`projects/{project_id}/databases/{database_id}`. (required)
- body: object, The request body. (required)
+ body: object, The request body.
The object takes the form of:
{ # The request for FirestoreAdmin.ExportDocuments.
@@ -140,56 +140,11 @@
},
"error": { # The `Status` type defines a logical error model that is suitable for # The error result of the operation in case of failure or cancellation.
# different programming environments, including REST APIs and RPC APIs. It is
- # used by [gRPC](https://github.com/grpc). The error model is designed to be:
+ # used by [gRPC](https://github.com/grpc). Each `Status` message contains
+ # three pieces of data: error code, error message, and error details.
#
- # - Simple to use and understand for most users
- # - Flexible enough to meet unexpected needs
- #
- # # Overview
- #
- # The `Status` message contains three pieces of data: error code, error
- # message, and error details. The error code should be an enum value of
- # google.rpc.Code, but it may accept additional error codes if needed. The
- # error message should be a developer-facing English message that helps
- # developers *understand* and *resolve* the error. If a localized user-facing
- # error message is needed, put the localized message in the error details or
- # localize it in the client. The optional error details may contain arbitrary
- # information about the error. There is a predefined set of error detail types
- # in the package `google.rpc` that can be used for common error conditions.
- #
- # # Language mapping
- #
- # The `Status` message is the logical representation of the error model, but it
- # is not necessarily the actual wire format. When the `Status` message is
- # exposed in different client libraries and different wire protocols, it can be
- # mapped differently. For example, it will likely be mapped to some exceptions
- # in Java, but more likely mapped to some error codes in C.
- #
- # # Other uses
- #
- # The error model and the `Status` message can be used in a variety of
- # environments, either with or without APIs, to provide a
- # consistent developer experience across different environments.
- #
- # Example uses of this error model include:
- #
- # - Partial errors. If a service needs to return partial errors to the client,
- # it may embed the `Status` in the normal response to indicate the partial
- # errors.
- #
- # - Workflow errors. A typical workflow has multiple steps. Each step may
- # have a `Status` message for error reporting.
- #
- # - Batch operations. If a client uses batch request and batch response, the
- # `Status` message should be used directly inside batch response, one for
- # each error sub-response.
- #
- # - Asynchronous operations. If an API call embeds asynchronous operation
- # results in its response, the status of those operations should be
- # represented directly using the `Status` message.
- #
- # - Logging. If some API errors are stored in logs, the message `Status` could
- # be used directly after any stripping needed for security/privacy reasons.
+ # You can find out more about this error model and how to work with it in the
+ # [API Design Guide](https://cloud.google.com/apis/design/errors).
"message": "A String", # A developer-facing error message, which should be in English. Any
# user-facing error message should be localized and sent in the
# google.rpc.Status.details field, or localized by the client.
@@ -216,12 +171,12 @@
},
"name": "A String", # The server-assigned name, which is only unique within the same service that
# originally returns it. If you use the default HTTP mapping, the
- # `name` should have the format of `operations/some/unique/name`.
+ # `name` should be a resource name ending with `operations/{unique_id}`.
}</pre>
</div>
<div class="method">
- <code class="details" id="importDocuments">importDocuments(name, body, x__xgafv=None)</code>
+ <code class="details" id="importDocuments">importDocuments(name, body=None, x__xgafv=None)</code>
<pre>Imports documents into Google Cloud Firestore. Existing documents with the
same name are overwritten. The import occurs in the background and its
progress can be monitored and managed via the Operation resource that is
@@ -231,7 +186,7 @@
Args:
name: string, Database to import into. Should be of the form:
`projects/{project_id}/databases/{database_id}`. (required)
- body: object, The request body. (required)
+ body: object, The request body.
The object takes the form of:
{ # The request for FirestoreAdmin.ImportDocuments.
@@ -264,56 +219,11 @@
},
"error": { # The `Status` type defines a logical error model that is suitable for # The error result of the operation in case of failure or cancellation.
# different programming environments, including REST APIs and RPC APIs. It is
- # used by [gRPC](https://github.com/grpc). The error model is designed to be:
+ # used by [gRPC](https://github.com/grpc). Each `Status` message contains
+ # three pieces of data: error code, error message, and error details.
#
- # - Simple to use and understand for most users
- # - Flexible enough to meet unexpected needs
- #
- # # Overview
- #
- # The `Status` message contains three pieces of data: error code, error
- # message, and error details. The error code should be an enum value of
- # google.rpc.Code, but it may accept additional error codes if needed. The
- # error message should be a developer-facing English message that helps
- # developers *understand* and *resolve* the error. If a localized user-facing
- # error message is needed, put the localized message in the error details or
- # localize it in the client. The optional error details may contain arbitrary
- # information about the error. There is a predefined set of error detail types
- # in the package `google.rpc` that can be used for common error conditions.
- #
- # # Language mapping
- #
- # The `Status` message is the logical representation of the error model, but it
- # is not necessarily the actual wire format. When the `Status` message is
- # exposed in different client libraries and different wire protocols, it can be
- # mapped differently. For example, it will likely be mapped to some exceptions
- # in Java, but more likely mapped to some error codes in C.
- #
- # # Other uses
- #
- # The error model and the `Status` message can be used in a variety of
- # environments, either with or without APIs, to provide a
- # consistent developer experience across different environments.
- #
- # Example uses of this error model include:
- #
- # - Partial errors. If a service needs to return partial errors to the client,
- # it may embed the `Status` in the normal response to indicate the partial
- # errors.
- #
- # - Workflow errors. A typical workflow has multiple steps. Each step may
- # have a `Status` message for error reporting.
- #
- # - Batch operations. If a client uses batch request and batch response, the
- # `Status` message should be used directly inside batch response, one for
- # each error sub-response.
- #
- # - Asynchronous operations. If an API call embeds asynchronous operation
- # results in its response, the status of those operations should be
- # represented directly using the `Status` message.
- #
- # - Logging. If some API errors are stored in logs, the message `Status` could
- # be used directly after any stripping needed for security/privacy reasons.
+ # You can find out more about this error model and how to work with it in the
+ # [API Design Guide](https://cloud.google.com/apis/design/errors).
"message": "A String", # A developer-facing error message, which should be in English. Any
# user-facing error message should be localized and sent in the
# google.rpc.Status.details field, or localized by the client.
@@ -340,7 +250,7 @@
},
"name": "A String", # The server-assigned name, which is only unique within the same service that
# originally returns it. If you use the default HTTP mapping, the
- # `name` should have the format of `operations/some/unique/name`.
+ # `name` should be a resource name ending with `operations/{unique_id}`.
}</pre>
</div>