google-apis-bigtableadmin_v2 0.54.0 → 0.56.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 8a3fe54a65c5ad6262b7a22fd2ee0ae30cbe99627a6dcef70e76a259dc1c5682
-  data.tar.gz: 1bc510d39a9b98abd34dc5b12d42e652a76df4949840b84fe3575757a1d2e2f8
+  metadata.gz: 6e23577923f63d62dc8a2b9d4d8ce2a86534ddf15d2c9c92464b5823928c2ad6
+  data.tar.gz: 02c01f31429b100fc87c41dbb8e71c63b130bded5a4c698530d9ab9834b6db81
 SHA512:
-  metadata.gz: 92f3bf0ddf939af846f46d032003842f37c2fc488f42d7cc1f58b090d3b0211a8b971a83f7950056a9558ed4085a961312eb5cea098b61241adbb0f45c2aac1c
-  data.tar.gz: 68364345b4905ae079120577e393744df96d791f6df2e43e52769b20b94d9296d140f3657ce3078aa6a63fc1d4007e26b23543c9ec0e55432d8c18afe75ba71d
+  metadata.gz: 58a87bb8529a70914249a5c6fe15d4744aa85f47d93a46f687c8e93af05fa37ec6ae2a2c09bdab7950913ded79e3bd25d185e296c1e12664eebffa760e735516
+  data.tar.gz: 1f2d37435e4b0ab7787563d766c39a7010a86168c3dd5e6f1b4e19de22c1a0037a6c9a15fce814239a4e01b1eb3e1d7d63e321ab370a7b43882323e172ccb164

data/CHANGELOG.md

@@ -1,5 +1,13 @@
 # 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
+
 ### v0.54.0 (2024-05-05)
 
 * Regenerated from discovery document revision 20240429

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.54.0"
+      GEM_VERSION = "0.56.0"
 
       # Version of the code generator used to generate this client
-      GENERATOR_VERSION = "0.14.0"
+      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.54.0
+  version: 0.56.0
 platform: ruby
 authors:
 - Google LLC
 autorequire: 
 bindir: bin
 cert_chain: []
-date: 2024-05-05 00:00:00.000000000 Z
+date: 2024-06-09 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: google-apis-core
@@ -16,7 +16,7 @@ dependencies:
     requirements:
     - - ">="
       - !ruby/object:Gem::Version
-        version: 0.14.0
+        version: 0.15.0
     - - "<"
       - !ruby/object:Gem::Version
         version: 2.a
@@ -26,7 +26,7 @@ dependencies:
     requirements:
     - - ">="
       - !ruby/object:Gem::Version
-        version: 0.14.0
+        version: 0.15.0
     - - "<"
       - !ruby/object:Gem::Version
         version: 2.a
@@ -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.54.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: []