chiu/google-api-ruby-client
1
0 Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Autogenerated update (2019-09-10)

Browse Source 
Delete:
- appstate_v1

Update:
- abusiveexperiencereport_v1
- adexperiencereport_v1
- analyticsreporting_v4
- androidmanagement_v1
- bigquery_v2
- bigtableadmin_v2
- binaryauthorization_v1beta1
- calendar_v3
- cloudasset_v1
- cloudasset_v1beta1
- cloudiot_v1
- cloudkms_v1
- cloudresourcemanager_v1
- cloudresourcemanager_v1beta1
- cloudresourcemanager_v2
- cloudresourcemanager_v2beta1
- cloudsearch_v1
- cloudtasks_v2beta3
- cloudtrace_v2
- commentanalyzer_v1alpha1
- composer_v1
- composer_v1beta1
- compute_alpha
- compute_beta
- compute_v1
- container_v1
- container_v1beta1
- content_v2
- content_v2_1
- dataflow_v1b3
- dataproc_v1
- dataproc_v1beta2
- datastore_v1
- datastore_v1beta1
- dfareporting_v3_1
- dialogflow_v2beta1
- dlp_v2
- docs_v1
- drive_v2
- drive_v3
- driveactivity_v2
- firestore_v1
- firestore_v1beta1
- firestore_v1beta2
- healthcare_v1alpha2
- healthcare_v1beta1
- logging_v2
- ml_v1
- monitoring_v3
- pagespeedonline_v5
- pubsub_v1
- pubsub_v1beta2
- run_v1alpha1
- runtimeconfig_v1beta1
- script_v1
- securitycenter_v1
- securitycenter_v1beta1
- serviceconsumermanagement_v1
- servicemanagement_v1
- servicenetworking_v1
- servicenetworking_v1beta
- serviceusage_v1
- serviceusage_v1beta1
- slides_v1
- speech_v1
- speech_v1p1beta1
- speech_v2beta
- sqladmin_v1beta4
- storage_v1
- storagetransfer_v1
- testing_v1
- toolresults_v1beta3
- translate_v3beta1
- vision_v1
- vision_v1p1beta1
- vision_v1p2beta1
- youtube_partner_v1
- youtube_v3
This commit is contained in:
Google APIs committed 2019-09-10 21:25:47 +00:00
1 parent 39975ca8dd
commit 300fd8ca30
234 files changed
+12877 -9106
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

generated/google/apis/datastore_v1beta1/classes.rb
+9 -75
View File
@@ -696,43 +696,10 @@ module Google
# The `Status` type defines a logical error model that is suitable for
# 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:
# - 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.
# used by [gRPC](https://github.com/grpc). Each `Status` message contains
# three pieces of data: error code, error message, and error details.
# 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).
# Corresponds to the JSON property `error`
# @return [Google::Apis::DatastoreV1beta1::Status]
attr_accessor :error
@@ -747,7 +714,7 @@ module Google
# 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``.
# Corresponds to the JSON property `name`
# @return [String]
attr_accessor :name
@@ -780,43 +747,10 @@ module Google
# The `Status` type defines a logical error model that is suitable for
# 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:
# - 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.
# used by [gRPC](https://github.com/grpc). Each `Status` message contains
# three pieces of data: error code, error message, and error details.
# 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).
class Status
include Google::Apis::Core::Hashable