google-apis-bigtableadmin_v2 0.55.0 → 0.57.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 21b790d4f6da0b0456790936f833c7b7820ab1a8a6f4ef125984b0b8b2ae8431
-  data.tar.gz: 9270cb4eff15e782b3d85d73eca226dc46089e39c7c36372559caaa916a7a742
+  metadata.gz: 9f2067c541f73d2053b94481e1aad921f404762d24c8ab1fb097f21af2341187
+  data.tar.gz: b14e6d46811af6aa61b4f1c4b077bf61cd7609ec7efc220724c357399e684603
 SHA512:
-  metadata.gz: 4cbe34dea0bfe3f12f00110604ede82fa08d4ffc717732f0076e19caa1151266c8d6cd34d1ebbf29d8edcf4cf4f02a037cc48a4688f3d339d646daff19db0afa
-  data.tar.gz: 8152a5dbd3ebde2bf85daac0334fbee941d8c9cc921e289122df779bd79ba095ce9e23571f57dd60f8979e447eec57b7f5c88b6c2067c28a781553a823c26b10
+  metadata.gz: 91eedb26003cf9c756fcf00293847c69fd8ecaf9eb5d70c0b6c712e33f9e1b54e7a448b9a46b3fab4c92846190cfdc25419082816d122132b844423972ffc295
+  data.tar.gz: 7863be2ef388ec7ab108df123bb04556672258aabdb0c1d06183f3cfdd7a40e7d73b945e8bb602409e8e44cc423ce58e4e1d5c4e7f066b278560e69de44f6130

data/CHANGELOG.md

@@ -1,5 +1,13 @@
 # Release history for google-apis-bigtableadmin_v2
 
+### v0.57.0 (2024-06-16)
+
+* Regenerated from discovery document revision 20240604
+
+### v0.56.0 (2024-06-09)
+
+* Regenerated from discovery document revision 20240522
+
 ### v0.55.0 (2024-05-19)
 
 * Regenerated using generator version 0.15.0

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

@@ -314,10 +314,10 @@ module Google
         # @return [String]
         attr_accessor :end_time
       
-        # Required. The expiration time of the backup, with microseconds granularity
-        # that must be at least 6 hours and at most 90 days from the time the request is
-        # received. Once the `expire_time` has passed, Cloud Bigtable will delete the
-        # backup and free the resources used by the backup.
+        # Required. The expiration time of the backup. When creating a backup or
+        # updating its `expire_time`, the new value must: - Be at most 90 days in the
+        # future - Be at least 6 hours in the future Once the `expire_time` has passed,
+        # Cloud Bigtable will delete the backup.
         # Corresponds to the JSON property `expireTime`
         # @return [String]
         attr_accessor :expire_time
@@ -771,19 +771,19 @@ module Google
         # Each link in the encoding chain also defines the following properties: *
         # Natural sort: Does the encoded value sort consistently with the original typed
         # value? Note that Bigtable will always sort data based on the raw encoded value,
-        # *not* the decoded type. - Example: STRING values sort in the same order as
-        # their UTF-8 encodings. - Counterexample: Encoding INT64 to a fixed-width
-        # STRING does *not* preserve sort order when dealing with negative numbers.
-        # INT64(1) > INT64(-1), but STRING("-00001") > STRING("00001). - The overall
-        # encoding chain sorts naturally if *every* link does. * Self-delimiting: If we
-        # concatenate two encoded values, can we always tell where the first one ends
-        # and the second one begins? - Example: If we encode INT64s to fixed-width
-        # STRINGs, the first value will always contain exactly N digits, possibly
-        # preceded by a sign. - Counterexample: If we concatenate two UTF-8 encoded
-        # STRINGs, we have no way to tell where the first one ends. - The overall
-        # encoding chain is self-delimiting if *any* link is. * Compatibility: Which
-        # other systems have matching encoding schemes? For example, does this encoding
-        # have a GoogleSQL equivalent? HBase? Java?
+        # *not* the decoded type. - Example: BYTES values sort in the same order as
+        # their raw encodings. - Counterexample: Encoding INT64 to a fixed-width STRING
+        # does *not* preserve sort order when dealing with negative numbers. INT64(1) >
+        # INT64(-1), but STRING("-00001") > STRING("00001). - The overall encoding chain
+        # has this property if *every* link does. * Self-delimiting: If we concatenate
+        # two encoded values, can we always tell where the first one ends and the second
+        # one begins? - Example: If we encode INT64s to fixed-width STRINGs, the first
+        # value will always contain exactly N digits, possibly preceded by a sign. -
+        # Counterexample: If we concatenate two UTF-8 encoded STRINGs, we have no way to
+        # tell where the first one ends. - The overall encoding chain has this property
+        # if *any* link does. * Compatibility: Which other systems have matching
+        # encoding schemes? For example, does this encoding have a GoogleSQL equivalent?
+        # HBase? Java?
         # Corresponds to the JSON property `valueType`
         # @return [Google::Apis::BigtableadminV2::Type]
         attr_accessor :value_type
@@ -1607,19 +1607,19 @@ module Google
         # Each link in the encoding chain also defines the following properties: *
         # Natural sort: Does the encoded value sort consistently with the original typed
         # value? Note that Bigtable will always sort data based on the raw encoded value,
-        # *not* the decoded type. - Example: STRING values sort in the same order as
-        # their UTF-8 encodings. - Counterexample: Encoding INT64 to a fixed-width
-        # STRING does *not* preserve sort order when dealing with negative numbers.
-        # INT64(1) > INT64(-1), but STRING("-00001") > STRING("00001). - The overall
-        # encoding chain sorts naturally if *every* link does. * Self-delimiting: If we
-        # concatenate two encoded values, can we always tell where the first one ends
-        # and the second one begins? - Example: If we encode INT64s to fixed-width
-        # STRINGs, the first value will always contain exactly N digits, possibly
-        # preceded by a sign. - Counterexample: If we concatenate two UTF-8 encoded
-        # STRINGs, we have no way to tell where the first one ends. - The overall
-        # encoding chain is self-delimiting if *any* link is. * Compatibility: Which
-        # other systems have matching encoding schemes? For example, does this encoding
-        # have a GoogleSQL equivalent? HBase? Java?
+        # *not* the decoded type. - Example: BYTES values sort in the same order as
+        # their raw encodings. - Counterexample: Encoding INT64 to a fixed-width STRING
+        # does *not* preserve sort order when dealing with negative numbers. INT64(1) >
+        # INT64(-1), but STRING("-00001") > STRING("00001). - The overall encoding chain
+        # has this property if *every* link does. * Self-delimiting: If we concatenate
+        # two encoded values, can we always tell where the first one ends and the second
+        # one begins? - Example: If we encode INT64s to fixed-width STRINGs, the first
+        # value will always contain exactly N digits, possibly preceded by a sign. -
+        # Counterexample: If we concatenate two UTF-8 encoded STRINGs, we have no way to
+        # tell where the first one ends. - The overall encoding chain has this property
+        # if *any* link does. * Compatibility: Which other systems have matching
+        # encoding schemes? For example, does this encoding have a GoogleSQL equivalent?
+        # HBase? Java?
         # Corresponds to the JSON property `inputType`
         # @return [Google::Apis::BigtableadminV2::Type]
         attr_accessor :input_type
@@ -1635,19 +1635,19 @@ module Google
         # Each link in the encoding chain also defines the following properties: *
         # Natural sort: Does the encoded value sort consistently with the original typed
         # value? Note that Bigtable will always sort data based on the raw encoded value,
-        # *not* the decoded type. - Example: STRING values sort in the same order as
-        # their UTF-8 encodings. - Counterexample: Encoding INT64 to a fixed-width
-        # STRING does *not* preserve sort order when dealing with negative numbers.
-        # INT64(1) > INT64(-1), but STRING("-00001") > STRING("00001). - The overall
-        # encoding chain sorts naturally if *every* link does. * Self-delimiting: If we
-        # concatenate two encoded values, can we always tell where the first one ends
-        # and the second one begins? - Example: If we encode INT64s to fixed-width
-        # STRINGs, the first value will always contain exactly N digits, possibly
-        # preceded by a sign. - Counterexample: If we concatenate two UTF-8 encoded
-        # STRINGs, we have no way to tell where the first one ends. - The overall
-        # encoding chain is self-delimiting if *any* link is. * Compatibility: Which
-        # other systems have matching encoding schemes? For example, does this encoding
-        # have a GoogleSQL equivalent? HBase? Java?
+        # *not* the decoded type. - Example: BYTES values sort in the same order as
+        # their raw encodings. - Counterexample: Encoding INT64 to a fixed-width STRING
+        # does *not* preserve sort order when dealing with negative numbers. INT64(1) >
+        # INT64(-1), but STRING("-00001") > STRING("00001). - The overall encoding chain
+        # has this property if *every* link does. * Self-delimiting: If we concatenate
+        # two encoded values, can we always tell where the first one ends and the second
+        # one begins? - Example: If we encode INT64s to fixed-width STRINGs, the first
+        # value will always contain exactly N digits, possibly preceded by a sign. -
+        # Counterexample: If we concatenate two UTF-8 encoded STRINGs, we have no way to
+        # tell where the first one ends. - The overall encoding chain has this property
+        # if *any* link does. * Compatibility: Which other systems have matching
+        # encoding schemes? For example, does this encoding have a GoogleSQL equivalent?
+        # HBase? Java?
         # Corresponds to the JSON property `stateType`
         # @return [Google::Apis::BigtableadminV2::Type]
         attr_accessor :state_type
@@ -3170,19 +3170,19 @@ module Google
       # Each link in the encoding chain also defines the following properties: *
       # Natural sort: Does the encoded value sort consistently with the original typed
       # value? Note that Bigtable will always sort data based on the raw encoded value,
-      # *not* the decoded type. - Example: STRING values sort in the same order as
-      # their UTF-8 encodings. - Counterexample: Encoding INT64 to a fixed-width
-      # STRING does *not* preserve sort order when dealing with negative numbers.
-      # INT64(1) > INT64(-1), but STRING("-00001") > STRING("00001). - The overall
-      # encoding chain sorts naturally if *every* link does. * Self-delimiting: If we
-      # concatenate two encoded values, can we always tell where the first one ends
-      # and the second one begins? - Example: If we encode INT64s to fixed-width
-      # STRINGs, the first value will always contain exactly N digits, possibly
-      # preceded by a sign. - Counterexample: If we concatenate two UTF-8 encoded
-      # STRINGs, we have no way to tell where the first one ends. - The overall
-      # encoding chain is self-delimiting if *any* link is. * Compatibility: Which
-      # other systems have matching encoding schemes? For example, does this encoding
-      # have a GoogleSQL equivalent? HBase? Java?
+      # *not* the decoded type. - Example: BYTES values sort in the same order as
+      # their raw encodings. - Counterexample: Encoding INT64 to a fixed-width STRING
+      # does *not* preserve sort order when dealing with negative numbers. INT64(1) >
+      # INT64(-1), but STRING("-00001") > STRING("00001). - The overall encoding chain
+      # has this property if *every* link does. * Self-delimiting: If we concatenate
+      # two encoded values, can we always tell where the first one ends and the second
+      # one begins? - Example: If we encode INT64s to fixed-width STRINGs, the first
+      # value will always contain exactly N digits, possibly preceded by a sign. -
+      # Counterexample: If we concatenate two UTF-8 encoded STRINGs, we have no way to
+      # tell where the first one ends. - The overall encoding chain has this property
+      # if *any* link does. * Compatibility: Which other systems have matching
+      # encoding schemes? For example, does this encoding have a GoogleSQL equivalent?
+      # HBase? Java?
       class Type
         include Google::Apis::Core::Hashable
       

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

@@ -16,13 +16,13 @@ module Google
   module Apis
     module BigtableadminV2
       # Version of the google-apis-bigtableadmin_v2 gem
-      GEM_VERSION = "0.55.0"
+      GEM_VERSION = "0.57.0"
 
       # Version of the code generator used to generate this client
       GENERATOR_VERSION = "0.15.0"
 
       # Revision of the discovery document this client was generated from
-      REVISION = "20240429"
+      REVISION = "20240604"
     end
   end
 end

metadata

@@ -1,14 +1,14 @@
 --- !ruby/object:Gem::Specification
 name: google-apis-bigtableadmin_v2
 version: !ruby/object:Gem::Version
-  version: 0.55.0
+  version: 0.57.0
 platform: ruby
 authors:
 - Google LLC
 autorequire: 
 bindir: bin
 cert_chain: []
-date: 2024-05-19 00:00:00.000000000 Z
+date: 2024-06-16 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/main/generated/google-apis-bigtableadmin_v2/CHANGELOG.md
-  documentation_uri: https://googleapis.dev/ruby/google-apis-bigtableadmin_v2/v0.55.0
+  documentation_uri: https://googleapis.dev/ruby/google-apis-bigtableadmin_v2/v0.57.0
   source_code_uri: https://github.com/googleapis/google-api-ruby-client/tree/main/generated/google-apis-bigtableadmin_v2
 post_install_message: 
 rdoc_options: []