google-apis-bigtableadmin_v2 0.62.0 → 0.64.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 12f7a2319362549383453c87ab4c5f498267ec362b6467f8f01d75fa87f0285d
-  data.tar.gz: fc0782e2a9290b03eb68d831e102308127ed26e2150a9e77f2f87ca98759e67e
+  metadata.gz: 1eb4773fe8c3471003afc43179f3153fd17556573908c28b2fb59b782ca791fc
+  data.tar.gz: 01137ca9e7548637463ad0d5ac77ea9f80d48573102c0628babf3574e962c99d
 SHA512:
-  metadata.gz: 2b978f8a0d49c651a9e47de8b0672e9b104f508406e573166a3276fcfa6e6cfe80a58fc7e294288bada0e2e32fb0ebb08891d949d15a22d37a965a980eb87b43
-  data.tar.gz: 9c140647d0182144fe88e7ae4a1f532bb58612e644f905b49b7bec335dfdddb3085f0ccd1cda829b7d05c3db0f298b1df4d2edd9804a8b7bdb877bb9f1a9a116
+  metadata.gz: c1064f1325e504246bdefd065f716dd029bcf7518c862d429e96079c1dc5f388909459d413714e8c4e579f1d97ac5211dcf8b9e312fd4aa953cb5e7d12deef33
+  data.tar.gz: 715fd48250a1e7155f5e0ab46a6b58c35d34f186c5e60eedfbd37ad19acc0a891aa2909dc6afa4230830b772d347b002ce983f9fe120a2114923ba6e70502f48

data/CHANGELOG.md

@@ -1,5 +1,13 @@
 # Release history for google-apis-bigtableadmin_v2
 
+### v0.64.0 (2024-10-20)
+
+* Regenerated from discovery document revision 20241008
+
+### v0.63.0 (2024-09-29)
+
+* Regenerated from discovery document revision 20240918
+
 ### v0.62.0 (2024-09-15)
 
 * Regenerated from discovery document revision 20240904

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

@@ -218,8 +218,8 @@ module Google
       class AutomatedBackupPolicy
         include Google::Apis::Core::Hashable
       
-        # Required. How frequently automated backups should occur. The only supported
-        # value at this time is 24 hours.
+        # How frequently automated backups should occur. The only supported value at
+        # this time is 24 hours. An undefined frequency is treated as 24 hours.
         # Corresponds to the JSON property `frequency`
         # @return [String]
         attr_accessor :frequency
@@ -659,6 +659,11 @@ module Google
         # @return [String]
         attr_accessor :name
       
+        # Immutable. The node scaling factor of this cluster.
+        # Corresponds to the JSON property `nodeScalingFactor`
+        # @return [String]
+        attr_accessor :node_scaling_factor
+      
         # The number of nodes in the cluster. If no value is set, Cloud Bigtable
         # automatically allocates nodes based on your data footprint and optimized for
         # 50% storage utilization.
@@ -682,6 +687,7 @@ module Google
           @encryption_config = args[:encryption_config] if args.key?(:encryption_config)
           @location = args[:location] if args.key?(:location)
           @name = args[:name] if args.key?(:name)
+          @node_scaling_factor = args[:node_scaling_factor] if args.key?(:node_scaling_factor)
           @serve_nodes = args[:serve_nodes] if args.key?(:serve_nodes)
           @state = args[:state] if args.key?(:state)
         end
@@ -781,21 +787,18 @@ module Google
         # Bigtable. It is heavily based on the GoogleSQL standard to help maintain
         # familiarity and consistency across products and features. For compatibility
         # with Bigtable's existing untyped APIs, each `Type` includes an `Encoding`
-        # which describes how to convert to/from the underlying data. Each encoding also
-        # defines the following properties: * Order-preserving: 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: BYTES values sort in the same order as their raw encodings. -
-        # Counterexample: Encoding INT64 as a fixed-width decimal string does *not*
-        # preserve sort order when dealing with negative numbers. `INT64(1) > INT64(-1)`,
-        # but `STRING("-00001") > STRING("00001)`. * 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. * Compatibility: Which other systems have
-        # matching encoding schemes? For example, does this encoding have a GoogleSQL
-        # equivalent? HBase? Java?
+        # which describes how to convert to or from the underlying data. Each encoding
+        # can operate in one of two modes: - Sorted: In this mode, Bigtable guarantees
+        # that `Encode(X) <= Encode(Y)` if and only if `X <= Y`. This is useful anywhere
+        # sort order is important, for example when encoding keys. - Distinct: In this
+        # mode, Bigtable guarantees that if `X != Y` then `Encode(X) != Encode(Y)`.
+        # However, the converse is not guaranteed. For example, both "`'foo': '1', 'bar':
+        # '2'`" and "`'bar': '2', 'foo': '1'`" are valid encodings of the same JSON
+        # value. The API clearly documents which mode is used wherever an encoding can
+        # be configured. Each encoding also documents which values are supported in
+        # which modes. For example, when encoding INT64 as a numeric STRING, negative
+        # numbers cannot be encoded in sorted mode. This is because `INT64(1) > INT64(-1)
+        # `, but `STRING("-00001") > STRING("00001")`.
         # Corresponds to the JSON property `valueType`
         # @return [Google::Apis::BigtableadminV2::Type]
         attr_accessor :value_type
@@ -1602,9 +1605,8 @@ module Google
       end
       
       # A value that combines incremental updates into a summarized value. Data is
-      # never directly written or read using type `Aggregate`. Writes will provide
-      # either the `input_type` or `state_type`, and reads will always return the `
-      # state_type` .
+      # never directly written or read using type `Aggregate`. Writes provide either
+      # the `input_type` or `state_type`, and reads always return the `state_type` .
       class GoogleBigtableAdminV2TypeAggregate
         include Google::Apis::Core::Hashable
       
@@ -1621,21 +1623,18 @@ module Google
         # Bigtable. It is heavily based on the GoogleSQL standard to help maintain
         # familiarity and consistency across products and features. For compatibility
         # with Bigtable's existing untyped APIs, each `Type` includes an `Encoding`
-        # which describes how to convert to/from the underlying data. Each encoding also
-        # defines the following properties: * Order-preserving: 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: BYTES values sort in the same order as their raw encodings. -
-        # Counterexample: Encoding INT64 as a fixed-width decimal string does *not*
-        # preserve sort order when dealing with negative numbers. `INT64(1) > INT64(-1)`,
-        # but `STRING("-00001") > STRING("00001)`. * 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. * Compatibility: Which other systems have
-        # matching encoding schemes? For example, does this encoding have a GoogleSQL
-        # equivalent? HBase? Java?
+        # which describes how to convert to or from the underlying data. Each encoding
+        # can operate in one of two modes: - Sorted: In this mode, Bigtable guarantees
+        # that `Encode(X) <= Encode(Y)` if and only if `X <= Y`. This is useful anywhere
+        # sort order is important, for example when encoding keys. - Distinct: In this
+        # mode, Bigtable guarantees that if `X != Y` then `Encode(X) != Encode(Y)`.
+        # However, the converse is not guaranteed. For example, both "`'foo': '1', 'bar':
+        # '2'`" and "`'bar': '2', 'foo': '1'`" are valid encodings of the same JSON
+        # value. The API clearly documents which mode is used wherever an encoding can
+        # be configured. Each encoding also documents which values are supported in
+        # which modes. For example, when encoding INT64 as a numeric STRING, negative
+        # numbers cannot be encoded in sorted mode. This is because `INT64(1) > INT64(-1)
+        # `, but `STRING("-00001") > STRING("00001")`.
         # Corresponds to the JSON property `inputType`
         # @return [Google::Apis::BigtableadminV2::Type]
         attr_accessor :input_type
@@ -1656,21 +1655,18 @@ module Google
         # Bigtable. It is heavily based on the GoogleSQL standard to help maintain
         # familiarity and consistency across products and features. For compatibility
         # with Bigtable's existing untyped APIs, each `Type` includes an `Encoding`
-        # which describes how to convert to/from the underlying data. Each encoding also
-        # defines the following properties: * Order-preserving: 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: BYTES values sort in the same order as their raw encodings. -
-        # Counterexample: Encoding INT64 as a fixed-width decimal string does *not*
-        # preserve sort order when dealing with negative numbers. `INT64(1) > INT64(-1)`,
-        # but `STRING("-00001") > STRING("00001)`. * 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. * Compatibility: Which other systems have
-        # matching encoding schemes? For example, does this encoding have a GoogleSQL
-        # equivalent? HBase? Java?
+        # which describes how to convert to or from the underlying data. Each encoding
+        # can operate in one of two modes: - Sorted: In this mode, Bigtable guarantees
+        # that `Encode(X) <= Encode(Y)` if and only if `X <= Y`. This is useful anywhere
+        # sort order is important, for example when encoding keys. - Distinct: In this
+        # mode, Bigtable guarantees that if `X != Y` then `Encode(X) != Encode(Y)`.
+        # However, the converse is not guaranteed. For example, both "`'foo': '1', 'bar':
+        # '2'`" and "`'bar': '2', 'foo': '1'`" are valid encodings of the same JSON
+        # value. The API clearly documents which mode is used wherever an encoding can
+        # be configured. Each encoding also documents which values are supported in
+        # which modes. For example, when encoding INT64 as a numeric STRING, negative
+        # numbers cannot be encoded in sorted mode. This is because `INT64(1) > INT64(-1)
+        # `, but `STRING("-00001") > STRING("00001")`.
         # Corresponds to the JSON property `stateType`
         # @return [Google::Apis::BigtableadminV2::Type]
         attr_accessor :state_type
@@ -1764,21 +1760,18 @@ module Google
         # Bigtable. It is heavily based on the GoogleSQL standard to help maintain
         # familiarity and consistency across products and features. For compatibility
         # with Bigtable's existing untyped APIs, each `Type` includes an `Encoding`
-        # which describes how to convert to/from the underlying data. Each encoding also
-        # defines the following properties: * Order-preserving: 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: BYTES values sort in the same order as their raw encodings. -
-        # Counterexample: Encoding INT64 as a fixed-width decimal string does *not*
-        # preserve sort order when dealing with negative numbers. `INT64(1) > INT64(-1)`,
-        # but `STRING("-00001") > STRING("00001)`. * 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. * Compatibility: Which other systems have
-        # matching encoding schemes? For example, does this encoding have a GoogleSQL
-        # equivalent? HBase? Java?
+        # which describes how to convert to or from the underlying data. Each encoding
+        # can operate in one of two modes: - Sorted: In this mode, Bigtable guarantees
+        # that `Encode(X) <= Encode(Y)` if and only if `X <= Y`. This is useful anywhere
+        # sort order is important, for example when encoding keys. - Distinct: In this
+        # mode, Bigtable guarantees that if `X != Y` then `Encode(X) != Encode(Y)`.
+        # However, the converse is not guaranteed. For example, both "`'foo': '1', 'bar':
+        # '2'`" and "`'bar': '2', 'foo': '1'`" are valid encodings of the same JSON
+        # value. The API clearly documents which mode is used wherever an encoding can
+        # be configured. Each encoding also documents which values are supported in
+        # which modes. For example, when encoding INT64 as a numeric STRING, negative
+        # numbers cannot be encoded in sorted mode. This is because `INT64(1) > INT64(-1)
+        # `, but `STRING("-00001") > STRING("00001")`.
         # Corresponds to the JSON property `elementType`
         # @return [Google::Apis::BigtableadminV2::Type]
         attr_accessor :element_type
@@ -1810,7 +1803,7 @@ module Google
       class GoogleBigtableAdminV2TypeBytes
         include Google::Apis::Core::Hashable
       
-        # Rules used to convert to/from lower level types.
+        # Rules used to convert to or from lower level types.
         # Corresponds to the JSON property `encoding`
         # @return [Google::Apis::BigtableadminV2::GoogleBigtableAdminV2TypeBytesEncoding]
         attr_accessor :encoding
@@ -1825,12 +1818,12 @@ module Google
         end
       end
       
-      # Rules used to convert to/from lower level types.
+      # Rules used to convert to or from lower level types.
       class GoogleBigtableAdminV2TypeBytesEncoding
         include Google::Apis::Core::Hashable
       
-        # Leaves the value "as-is" * Order-preserving? Yes * Self-delimiting? No *
-        # Compatibility? N/A
+        # Leaves the value as-is. Sorted mode: all values are supported. Distinct mode:
+        # all values are supported.
         # Corresponds to the JSON property `raw`
         # @return [Google::Apis::BigtableadminV2::GoogleBigtableAdminV2TypeBytesEncodingRaw]
         attr_accessor :raw
@@ -1845,8 +1838,8 @@ module Google
         end
       end
       
-      # Leaves the value "as-is" * Order-preserving? Yes * Self-delimiting? No *
-      # Compatibility? N/A
+      # Leaves the value as-is. Sorted mode: all values are supported. Distinct mode:
+      # all values are supported.
       class GoogleBigtableAdminV2TypeBytesEncodingRaw
         include Google::Apis::Core::Hashable
       
@@ -1902,7 +1895,7 @@ module Google
       class GoogleBigtableAdminV2TypeInt64
         include Google::Apis::Core::Hashable
       
-        # Rules used to convert to/from lower level types.
+        # Rules used to convert to or from lower level types.
         # Corresponds to the JSON property `encoding`
         # @return [Google::Apis::BigtableadminV2::GoogleBigtableAdminV2TypeInt64Encoding]
         attr_accessor :encoding
@@ -1917,14 +1910,14 @@ module Google
         end
       end
       
-      # Rules used to convert to/from lower level types.
+      # Rules used to convert to or from lower level types.
       class GoogleBigtableAdminV2TypeInt64Encoding
         include Google::Apis::Core::Hashable
       
-        # Encodes the value as an 8-byte big endian twos complement `Bytes` value. *
-        # Order-preserving? No (positive values only) * Self-delimiting? Yes *
-        # Compatibility? - BigQuery Federation `BINARY` encoding - HBase `Bytes.toBytes`
-        # - Java `ByteBuffer.putLong()` with `ByteOrder.BIG_ENDIAN`
+        # Encodes the value as an 8-byte big-endian two's complement value. Sorted mode:
+        # non-negative values are supported. Distinct mode: all values are supported.
+        # Compatible with: - BigQuery `BINARY` encoding - HBase `Bytes.toBytes` - Java `
+        # ByteBuffer.putLong()` with `ByteOrder.BIG_ENDIAN`
         # Corresponds to the JSON property `bigEndianBytes`
         # @return [Google::Apis::BigtableadminV2::GoogleBigtableAdminV2TypeInt64EncodingBigEndianBytes]
         attr_accessor :big_endian_bytes
@@ -1939,10 +1932,10 @@ module Google
         end
       end
       
-      # Encodes the value as an 8-byte big endian twos complement `Bytes` value. *
-      # Order-preserving? No (positive values only) * Self-delimiting? Yes *
-      # Compatibility? - BigQuery Federation `BINARY` encoding - HBase `Bytes.toBytes`
-      # - Java `ByteBuffer.putLong()` with `ByteOrder.BIG_ENDIAN`
+      # Encodes the value as an 8-byte big-endian two's complement value. Sorted mode:
+      # non-negative values are supported. Distinct mode: all values are supported.
+      # Compatible with: - BigQuery `BINARY` encoding - HBase `Bytes.toBytes` - Java `
+      # ByteBuffer.putLong()` with `ByteOrder.BIG_ENDIAN`
       class GoogleBigtableAdminV2TypeInt64EncodingBigEndianBytes
         include Google::Apis::Core::Hashable
       
@@ -1974,21 +1967,18 @@ module Google
         # Bigtable. It is heavily based on the GoogleSQL standard to help maintain
         # familiarity and consistency across products and features. For compatibility
         # with Bigtable's existing untyped APIs, each `Type` includes an `Encoding`
-        # which describes how to convert to/from the underlying data. Each encoding also
-        # defines the following properties: * Order-preserving: 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: BYTES values sort in the same order as their raw encodings. -
-        # Counterexample: Encoding INT64 as a fixed-width decimal string does *not*
-        # preserve sort order when dealing with negative numbers. `INT64(1) > INT64(-1)`,
-        # but `STRING("-00001") > STRING("00001)`. * 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. * Compatibility: Which other systems have
-        # matching encoding schemes? For example, does this encoding have a GoogleSQL
-        # equivalent? HBase? Java?
+        # which describes how to convert to or from the underlying data. Each encoding
+        # can operate in one of two modes: - Sorted: In this mode, Bigtable guarantees
+        # that `Encode(X) <= Encode(Y)` if and only if `X <= Y`. This is useful anywhere
+        # sort order is important, for example when encoding keys. - Distinct: In this
+        # mode, Bigtable guarantees that if `X != Y` then `Encode(X) != Encode(Y)`.
+        # However, the converse is not guaranteed. For example, both "`'foo': '1', 'bar':
+        # '2'`" and "`'bar': '2', 'foo': '1'`" are valid encodings of the same JSON
+        # value. The API clearly documents which mode is used wherever an encoding can
+        # be configured. Each encoding also documents which values are supported in
+        # which modes. For example, when encoding INT64 as a numeric STRING, negative
+        # numbers cannot be encoded in sorted mode. This is because `INT64(1) > INT64(-1)
+        # `, but `STRING("-00001") > STRING("00001")`.
         # Corresponds to the JSON property `keyType`
         # @return [Google::Apis::BigtableadminV2::Type]
         attr_accessor :key_type
@@ -1997,21 +1987,18 @@ module Google
         # Bigtable. It is heavily based on the GoogleSQL standard to help maintain
         # familiarity and consistency across products and features. For compatibility
         # with Bigtable's existing untyped APIs, each `Type` includes an `Encoding`
-        # which describes how to convert to/from the underlying data. Each encoding also
-        # defines the following properties: * Order-preserving: 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: BYTES values sort in the same order as their raw encodings. -
-        # Counterexample: Encoding INT64 as a fixed-width decimal string does *not*
-        # preserve sort order when dealing with negative numbers. `INT64(1) > INT64(-1)`,
-        # but `STRING("-00001") > STRING("00001)`. * 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. * Compatibility: Which other systems have
-        # matching encoding schemes? For example, does this encoding have a GoogleSQL
-        # equivalent? HBase? Java?
+        # which describes how to convert to or from the underlying data. Each encoding
+        # can operate in one of two modes: - Sorted: In this mode, Bigtable guarantees
+        # that `Encode(X) <= Encode(Y)` if and only if `X <= Y`. This is useful anywhere
+        # sort order is important, for example when encoding keys. - Distinct: In this
+        # mode, Bigtable guarantees that if `X != Y` then `Encode(X) != Encode(Y)`.
+        # However, the converse is not guaranteed. For example, both "`'foo': '1', 'bar':
+        # '2'`" and "`'bar': '2', 'foo': '1'`" are valid encodings of the same JSON
+        # value. The API clearly documents which mode is used wherever an encoding can
+        # be configured. Each encoding also documents which values are supported in
+        # which modes. For example, when encoding INT64 as a numeric STRING, negative
+        # numbers cannot be encoded in sorted mode. This is because `INT64(1) > INT64(-1)
+        # `, but `STRING("-00001") > STRING("00001")`.
         # Corresponds to the JSON property `valueType`
         # @return [Google::Apis::BigtableadminV2::Type]
         attr_accessor :value_type
@@ -2031,7 +2018,7 @@ module Google
       class GoogleBigtableAdminV2TypeString
         include Google::Apis::Core::Hashable
       
-        # Rules used to convert to/from lower level types.
+        # Rules used to convert to or from lower level types.
         # Corresponds to the JSON property `encoding`
         # @return [Google::Apis::BigtableadminV2::GoogleBigtableAdminV2TypeStringEncoding]
         attr_accessor :encoding
@@ -2046,13 +2033,14 @@ module Google
         end
       end
       
-      # Rules used to convert to/from lower level types.
+      # Rules used to convert to or from lower level types.
       class GoogleBigtableAdminV2TypeStringEncoding
         include Google::Apis::Core::Hashable
       
-        # UTF-8 encoding * Order-preserving? Yes (code point order) * Self-delimiting?
-        # No * Compatibility? - BigQuery Federation `TEXT` encoding - HBase `Bytes.
-        # toBytes` - Java `String#getBytes(StandardCharsets.UTF_8)`
+        # UTF-8 encoding. Sorted mode: - All values are supported. - Code point order is
+        # preserved. Distinct mode: all values are supported. Compatible with: -
+        # BigQuery `TEXT` encoding - HBase `Bytes.toBytes` - Java `String#getBytes(
+        # StandardCharsets.UTF_8)`
         # Corresponds to the JSON property `utf8Bytes`
         # @return [Google::Apis::BigtableadminV2::GoogleBigtableAdminV2TypeStringEncodingUtf8Bytes]
         attr_accessor :utf8_bytes
@@ -2073,9 +2061,10 @@ module Google
         end
       end
       
-      # UTF-8 encoding * Order-preserving? Yes (code point order) * Self-delimiting?
-      # No * Compatibility? - BigQuery Federation `TEXT` encoding - HBase `Bytes.
-      # toBytes` - Java `String#getBytes(StandardCharsets.UTF_8)`
+      # UTF-8 encoding. Sorted mode: - All values are supported. - Code point order is
+      # preserved. Distinct mode: all values are supported. Compatible with: -
+      # BigQuery `TEXT` encoding - HBase `Bytes.toBytes` - Java `String#getBytes(
+      # StandardCharsets.UTF_8)`
       class GoogleBigtableAdminV2TypeStringEncodingUtf8Bytes
         include Google::Apis::Core::Hashable
       
@@ -2136,21 +2125,18 @@ module Google
         # Bigtable. It is heavily based on the GoogleSQL standard to help maintain
         # familiarity and consistency across products and features. For compatibility
         # with Bigtable's existing untyped APIs, each `Type` includes an `Encoding`
-        # which describes how to convert to/from the underlying data. Each encoding also
-        # defines the following properties: * Order-preserving: 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: BYTES values sort in the same order as their raw encodings. -
-        # Counterexample: Encoding INT64 as a fixed-width decimal string does *not*
-        # preserve sort order when dealing with negative numbers. `INT64(1) > INT64(-1)`,
-        # but `STRING("-00001") > STRING("00001)`. * 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. * Compatibility: Which other systems have
-        # matching encoding schemes? For example, does this encoding have a GoogleSQL
-        # equivalent? HBase? Java?
+        # which describes how to convert to or from the underlying data. Each encoding
+        # can operate in one of two modes: - Sorted: In this mode, Bigtable guarantees
+        # that `Encode(X) <= Encode(Y)` if and only if `X <= Y`. This is useful anywhere
+        # sort order is important, for example when encoding keys. - Distinct: In this
+        # mode, Bigtable guarantees that if `X != Y` then `Encode(X) != Encode(Y)`.
+        # However, the converse is not guaranteed. For example, both "`'foo': '1', 'bar':
+        # '2'`" and "`'bar': '2', 'foo': '1'`" are valid encodings of the same JSON
+        # value. The API clearly documents which mode is used wherever an encoding can
+        # be configured. Each encoding also documents which values are supported in
+        # which modes. For example, when encoding INT64 as a numeric STRING, negative
+        # numbers cannot be encoded in sorted mode. This is because `INT64(1) > INT64(-1)
+        # `, but `STRING("-00001") > STRING("00001")`.
         # Corresponds to the JSON property `type`
         # @return [Google::Apis::BigtableadminV2::Type]
         attr_accessor :type
@@ -2736,11 +2722,15 @@ module Google
         # @return [Array<String>]
         attr_accessor :cluster_ids
       
-        # If enabled, the AFE will route the request based on the row key of the request,
-        # rather than randomly. Instead, each row key will be assigned to a cluster,
-        # and will stick to that cluster. If clusters are added or removed, then this
-        # may affect which row keys stick to which clusters. To avoid this, users can
-        # specify a group cluster.
+        # If enabled, Bigtable will route the request based on the row key of the
+        # request, rather than randomly. Instead, each row key will be assigned to a
+        # cluster, and will stick to that cluster. If clusters are added or removed,
+        # then this may affect which row keys stick to which clusters. To avoid this,
+        # users can use a cluster group to specify which clusters are to be used. In
+        # this case, new clusters that are not a part of the cluster group will not be
+        # routed to, and routing will be unaffected by the new cluster. Moreover,
+        # clusters specified in the cluster group cannot be deleted unless removed from
+        # the cluster group.
         # Corresponds to the JSON property `rowAffinity`
         # @return [Google::Apis::BigtableadminV2::RowAffinity]
         attr_accessor :row_affinity
@@ -3162,11 +3152,15 @@ module Google
         end
       end
       
-      # If enabled, the AFE will route the request based on the row key of the request,
-      # rather than randomly. Instead, each row key will be assigned to a cluster,
-      # and will stick to that cluster. If clusters are added or removed, then this
-      # may affect which row keys stick to which clusters. To avoid this, users can
-      # specify a group cluster.
+      # If enabled, Bigtable will route the request based on the row key of the
+      # request, rather than randomly. Instead, each row key will be assigned to a
+      # cluster, and will stick to that cluster. If clusters are added or removed,
+      # then this may affect which row keys stick to which clusters. To avoid this,
+      # users can use a cluster group to specify which clusters are to be used. In
+      # this case, new clusters that are not a part of the cluster group will not be
+      # routed to, and routing will be unaffected by the new cluster. Moreover,
+      # clusters specified in the cluster group cannot be deleted unless removed from
+      # the cluster group.
       class RowAffinity
         include Google::Apis::Core::Hashable
       
@@ -3569,28 +3563,24 @@ module Google
       # Bigtable. It is heavily based on the GoogleSQL standard to help maintain
       # familiarity and consistency across products and features. For compatibility
       # with Bigtable's existing untyped APIs, each `Type` includes an `Encoding`
-      # which describes how to convert to/from the underlying data. Each encoding also
-      # defines the following properties: * Order-preserving: 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: BYTES values sort in the same order as their raw encodings. -
-      # Counterexample: Encoding INT64 as a fixed-width decimal string does *not*
-      # preserve sort order when dealing with negative numbers. `INT64(1) > INT64(-1)`,
-      # but `STRING("-00001") > STRING("00001)`. * 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. * Compatibility: Which other systems have
-      # matching encoding schemes? For example, does this encoding have a GoogleSQL
-      # equivalent? HBase? Java?
+      # which describes how to convert to or from the underlying data. Each encoding
+      # can operate in one of two modes: - Sorted: In this mode, Bigtable guarantees
+      # that `Encode(X) <= Encode(Y)` if and only if `X <= Y`. This is useful anywhere
+      # sort order is important, for example when encoding keys. - Distinct: In this
+      # mode, Bigtable guarantees that if `X != Y` then `Encode(X) != Encode(Y)`.
+      # However, the converse is not guaranteed. For example, both "`'foo': '1', 'bar':
+      # '2'`" and "`'bar': '2', 'foo': '1'`" are valid encodings of the same JSON
+      # value. The API clearly documents which mode is used wherever an encoding can
+      # be configured. Each encoding also documents which values are supported in
+      # which modes. For example, when encoding INT64 as a numeric STRING, negative
+      # numbers cannot be encoded in sorted mode. This is because `INT64(1) > INT64(-1)
+      # `, but `STRING("-00001") > STRING("00001")`.
       class Type
         include Google::Apis::Core::Hashable
       
         # A value that combines incremental updates into a summarized value. Data is
-        # never directly written or read using type `Aggregate`. Writes will provide
-        # either the `input_type` or `state_type`, and reads will always return the `
-        # state_type` .
+        # never directly written or read using type `Aggregate`. Writes provide either
+        # the `input_type` or `state_type`, and reads always return the `state_type` .
         # Corresponds to the JSON property `aggregateType`
         # @return [Google::Apis::BigtableadminV2::GoogleBigtableAdminV2TypeAggregate]
         attr_accessor :aggregate_type

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.62.0"
+      GEM_VERSION = "0.64.0"
 
       # Version of the code generator used to generate this client
       GENERATOR_VERSION = "0.15.1"
 
       # Revision of the discovery document this client was generated from
-      REVISION = "20240904"
+      REVISION = "20241008"
     end
   end
 end

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

@@ -856,6 +856,7 @@ module Google
       
           property :location, as: 'location'
           property :name, as: 'name'
+          property :node_scaling_factor, as: 'nodeScalingFactor'
           property :serve_nodes, as: 'serveNodes'
           property :state, as: 'state'
         end

metadata

@@ -1,14 +1,14 @@
 --- !ruby/object:Gem::Specification
 name: google-apis-bigtableadmin_v2
 version: !ruby/object:Gem::Version
-  version: 0.62.0
+  version: 0.64.0
 platform: ruby
 authors:
 - Google LLC
 autorequire: 
 bindir: bin
 cert_chain: []
-date: 2024-09-15 00:00:00.000000000 Z
+date: 2024-10-27 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.62.0
+  documentation_uri: https://googleapis.dev/ruby/google-apis-bigtableadmin_v2/v0.64.0
   source_code_uri: https://github.com/googleapis/google-api-ruby-client/tree/main/generated/google-apis-bigtableadmin_v2
 post_install_message: 
 rdoc_options: []
@@ -75,7 +75,7 @@ required_rubygems_version: !ruby/object:Gem::Requirement
     - !ruby/object:Gem::Version
       version: '0'
 requirements: []
-rubygems_version: 3.5.6
+rubygems_version: 3.5.21
 signing_key: 
 specification_version: 4
 summary: Simple REST client for Cloud Bigtable Admin API V2