feat: Automated regeneration of bigtableadmin v2 client (#19551)

Auto-created at 2024-06-09 09:29:20 +0000 using the toys pull request generator.

Author: yoshi-code-bot

generated/google-apis-bigtableadmin_v2/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

generated/google-apis-bigtableadmin_v2/lib/google/apis/bigtableadmin_v2/classes.rb

@@ -771,19 +771,19 @@ class ColumnFamily
         # 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 @@ class GoogleBigtableAdminV2TypeAggregate
         # 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 @@ class GoogleBigtableAdminV2TypeAggregate
         # 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 @@ def update!(**args)
       # 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
 

generated/google-apis-bigtableadmin_v2/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