google-apis-bigtableadmin_v2 0.55.0 → 0.56.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 21b790d4f6da0b0456790936f833c7b7820ab1a8a6f4ef125984b0b8b2ae8431
-  data.tar.gz: 9270cb4eff15e782b3d85d73eca226dc46089e39c7c36372559caaa916a7a742
+  metadata.gz: 6e23577923f63d62dc8a2b9d4d8ce2a86534ddf15d2c9c92464b5823928c2ad6
+  data.tar.gz: 02c01f31429b100fc87c41dbb8e71c63b130bded5a4c698530d9ab9834b6db81
 SHA512:
-  metadata.gz: 4cbe34dea0bfe3f12f00110604ede82fa08d4ffc717732f0076e19caa1151266c8d6cd34d1ebbf29d8edcf4cf4f02a037cc48a4688f3d339d646daff19db0afa
-  data.tar.gz: 8152a5dbd3ebde2bf85daac0334fbee941d8c9cc921e289122df779bd79ba095ce9e23571f57dd60f8979e447eec57b7f5c88b6c2067c28a781553a823c26b10
+  metadata.gz: 58a87bb8529a70914249a5c6fe15d4744aa85f47d93a46f687c8e93af05fa37ec6ae2a2c09bdab7950913ded79e3bd25d185e296c1e12664eebffa760e735516
+  data.tar.gz: 1f2d37435e4b0ab7787563d766c39a7010a86168c3dd5e6f1b4e19de22c1a0037a6c9a15fce814239a4e01b1eb3e1d7d63e321ab370a7b43882323e172ccb164

data/CHANGELOG.md

@@ -1,5 +1,9 @@
 # Release history for google-apis-bigtableadmin_v2
 
+### 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

@@ -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.56.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 = "20240522"
     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.56.0
 platform: ruby
 authors:
 - Google LLC
 autorequire: 
 bindir: bin
 cert_chain: []
-date: 2024-05-19 00:00:00.000000000 Z
+date: 2024-06-09 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.56.0
   source_code_uri: https://github.com/googleapis/google-api-ruby-client/tree/main/generated/google-apis-bigtableadmin_v2
 post_install_message: 
 rdoc_options: []