From 3ebffd132f25c1eab2caac0e0992cc1b8ab0bca2 Mon Sep 17 00:00:00 2001 From: Yoshi Automation Date: Tue, 26 Mar 2024 07:08:30 +0000 Subject: [PATCH] feat(bigtableadmin): update the api #### bigtableadmin:v2 The following keys were added: - schemas.AppProfile.properties.dataBoostIsolationReadOnly.$ref (Total Keys: 1) - schemas.CheckConsistencyRequest.properties.dataBoostReadLocalWrites.$ref (Total Keys: 1) - schemas.CheckConsistencyRequest.properties.standardReadRemoteWrites.$ref (Total Keys: 1) - schemas.ColumnFamily.properties.valueType.$ref (Total Keys: 1) - schemas.DataBoostIsolationReadOnly (Total Keys: 3) - schemas.DataBoostReadLocalWrites (Total Keys: 2) - schemas.GoogleBigtableAdminV2TypeAggregate (Total Keys: 8) - schemas.GoogleBigtableAdminV2TypeBytes (Total Keys: 8) - schemas.GoogleBigtableAdminV2TypeInt64 (Total Keys: 9) - schemas.StandardReadRemoteWrites (Total Keys: 2) - schemas.Type (Total Keys: 5) --- ...min_v2.projects.instances.appProfiles.html | 15 ++ ...bleadmin_v2.projects.instances.tables.html | 212 ++++++++++++++++++ .../documents/bigtableadmin.v2.json | 155 ++++++++++++- 3 files changed, 381 insertions(+), 1 deletion(-) diff --git a/docs/dyn/bigtableadmin_v2.projects.instances.appProfiles.html b/docs/dyn/bigtableadmin_v2.projects.instances.appProfiles.html index 0792fa95a3..2c9e6811e1 100644 --- a/docs/dyn/bigtableadmin_v2.projects.instances.appProfiles.html +++ b/docs/dyn/bigtableadmin_v2.projects.instances.appProfiles.html @@ -111,6 +111,9 @@

Method Details

The object takes the form of: { # A configuration object describing how Cloud Bigtable should treat traffic from a particular end user application. + "dataBoostIsolationReadOnly": { # Data Boost is a serverless compute capability that lets you run high-throughput read jobs on your Bigtable data, without impacting the performance of the clusters that handle your application traffic. Currently, Data Boost exclusively supports read-only use-cases with single-cluster routing. Data Boost reads are only guaranteed to see the results of writes that were written at least 30 minutes ago. This means newly written values may not become visible for up to 30m, and also means that old values may remain visible for up to 30m after being deleted or overwritten. To mitigate the staleness of the data, users may either wait 30m, or use CheckConsistency. # Specifies that this app profile is intended for read-only usage via the Data Boost feature. + "computeBillingOwner": "A String", # The Compute Billing Owner for this Data Boost App Profile. + }, "description": "A String", # Long form description of the use case for this AppProfile. "etag": "A String", # Strongly validated etag for optimistic concurrency control. Preserve the value returned from `GetAppProfile` when calling `UpdateAppProfile` to fail the request if there has been a modification in the mean time. The `update_mask` of the request need not include `etag` for this protection to apply. See [Wikipedia](https://en.wikipedia.org/wiki/HTTP_ETag) and [RFC 7232](https://tools.ietf.org/html/rfc7232#section-2.3) for more details. "multiClusterRoutingUseAny": { # Read/write requests are routed to the nearest cluster in the instance, and will fail over to the nearest cluster that is available in the event of transient errors or delays. Clusters in a region are considered equidistant. Choosing this option sacrifices read-your-writes consistency to improve availability. # Use a multi-cluster routing policy. @@ -140,6 +143,9 @@

Method Details

An object of the form: { # A configuration object describing how Cloud Bigtable should treat traffic from a particular end user application. + "dataBoostIsolationReadOnly": { # Data Boost is a serverless compute capability that lets you run high-throughput read jobs on your Bigtable data, without impacting the performance of the clusters that handle your application traffic. Currently, Data Boost exclusively supports read-only use-cases with single-cluster routing. Data Boost reads are only guaranteed to see the results of writes that were written at least 30 minutes ago. This means newly written values may not become visible for up to 30m, and also means that old values may remain visible for up to 30m after being deleted or overwritten. To mitigate the staleness of the data, users may either wait 30m, or use CheckConsistency. # Specifies that this app profile is intended for read-only usage via the Data Boost feature. + "computeBillingOwner": "A String", # The Compute Billing Owner for this Data Boost App Profile. + }, "description": "A String", # Long form description of the use case for this AppProfile. "etag": "A String", # Strongly validated etag for optimistic concurrency control. Preserve the value returned from `GetAppProfile` when calling `UpdateAppProfile` to fail the request if there has been a modification in the mean time. The `update_mask` of the request need not include `etag` for this protection to apply. See [Wikipedia](https://en.wikipedia.org/wiki/HTTP_ETag) and [RFC 7232](https://tools.ietf.org/html/rfc7232#section-2.3) for more details. "multiClusterRoutingUseAny": { # Read/write requests are routed to the nearest cluster in the instance, and will fail over to the nearest cluster that is available in the event of transient errors or delays. Clusters in a region are considered equidistant. Choosing this option sacrifices read-your-writes consistency to improve availability. # Use a multi-cluster routing policy. @@ -193,6 +199,9 @@

Method Details

An object of the form: { # A configuration object describing how Cloud Bigtable should treat traffic from a particular end user application. + "dataBoostIsolationReadOnly": { # Data Boost is a serverless compute capability that lets you run high-throughput read jobs on your Bigtable data, without impacting the performance of the clusters that handle your application traffic. Currently, Data Boost exclusively supports read-only use-cases with single-cluster routing. Data Boost reads are only guaranteed to see the results of writes that were written at least 30 minutes ago. This means newly written values may not become visible for up to 30m, and also means that old values may remain visible for up to 30m after being deleted or overwritten. To mitigate the staleness of the data, users may either wait 30m, or use CheckConsistency. # Specifies that this app profile is intended for read-only usage via the Data Boost feature. + "computeBillingOwner": "A String", # The Compute Billing Owner for this Data Boost App Profile. + }, "description": "A String", # Long form description of the use case for this AppProfile. "etag": "A String", # Strongly validated etag for optimistic concurrency control. Preserve the value returned from `GetAppProfile` when calling `UpdateAppProfile` to fail the request if there has been a modification in the mean time. The `update_mask` of the request need not include `etag` for this protection to apply. See [Wikipedia](https://en.wikipedia.org/wiki/HTTP_ETag) and [RFC 7232](https://tools.ietf.org/html/rfc7232#section-2.3) for more details. "multiClusterRoutingUseAny": { # Read/write requests are routed to the nearest cluster in the instance, and will fail over to the nearest cluster that is available in the event of transient errors or delays. Clusters in a region are considered equidistant. Choosing this option sacrifices read-your-writes consistency to improve availability. # Use a multi-cluster routing policy. @@ -231,6 +240,9 @@

Method Details

{ # Response message for BigtableInstanceAdmin.ListAppProfiles. "appProfiles": [ # The list of requested app profiles. { # A configuration object describing how Cloud Bigtable should treat traffic from a particular end user application. + "dataBoostIsolationReadOnly": { # Data Boost is a serverless compute capability that lets you run high-throughput read jobs on your Bigtable data, without impacting the performance of the clusters that handle your application traffic. Currently, Data Boost exclusively supports read-only use-cases with single-cluster routing. Data Boost reads are only guaranteed to see the results of writes that were written at least 30 minutes ago. This means newly written values may not become visible for up to 30m, and also means that old values may remain visible for up to 30m after being deleted or overwritten. To mitigate the staleness of the data, users may either wait 30m, or use CheckConsistency. # Specifies that this app profile is intended for read-only usage via the Data Boost feature. + "computeBillingOwner": "A String", # The Compute Billing Owner for this Data Boost App Profile. + }, "description": "A String", # Long form description of the use case for this AppProfile. "etag": "A String", # Strongly validated etag for optimistic concurrency control. Preserve the value returned from `GetAppProfile` when calling `UpdateAppProfile` to fail the request if there has been a modification in the mean time. The `update_mask` of the request need not include `etag` for this protection to apply. See [Wikipedia](https://en.wikipedia.org/wiki/HTTP_ETag) and [RFC 7232](https://tools.ietf.org/html/rfc7232#section-2.3) for more details. "multiClusterRoutingUseAny": { # Read/write requests are routed to the nearest cluster in the instance, and will fail over to the nearest cluster that is available in the event of transient errors or delays. Clusters in a region are considered equidistant. Choosing this option sacrifices read-your-writes consistency to improve availability. # Use a multi-cluster routing policy. @@ -280,6 +292,9 @@

Method Details

The object takes the form of: { # A configuration object describing how Cloud Bigtable should treat traffic from a particular end user application. + "dataBoostIsolationReadOnly": { # Data Boost is a serverless compute capability that lets you run high-throughput read jobs on your Bigtable data, without impacting the performance of the clusters that handle your application traffic. Currently, Data Boost exclusively supports read-only use-cases with single-cluster routing. Data Boost reads are only guaranteed to see the results of writes that were written at least 30 minutes ago. This means newly written values may not become visible for up to 30m, and also means that old values may remain visible for up to 30m after being deleted or overwritten. To mitigate the staleness of the data, users may either wait 30m, or use CheckConsistency. # Specifies that this app profile is intended for read-only usage via the Data Boost feature. + "computeBillingOwner": "A String", # The Compute Billing Owner for this Data Boost App Profile. + }, "description": "A String", # Long form description of the use case for this AppProfile. "etag": "A String", # Strongly validated etag for optimistic concurrency control. Preserve the value returned from `GetAppProfile` when calling `UpdateAppProfile` to fail the request if there has been a modification in the mean time. The `update_mask` of the request need not include `etag` for this protection to apply. See [Wikipedia](https://en.wikipedia.org/wiki/HTTP_ETag) and [RFC 7232](https://tools.ietf.org/html/rfc7232#section-2.3) for more details. "multiClusterRoutingUseAny": { # Read/write requests are routed to the nearest cluster in the instance, and will fail over to the nearest cluster that is available in the event of transient errors or delays. Clusters in a region are considered equidistant. Choosing this option sacrifices read-your-writes consistency to improve availability. # Use a multi-cluster routing policy. diff --git a/docs/dyn/bigtableadmin_v2.projects.instances.tables.html b/docs/dyn/bigtableadmin_v2.projects.instances.tables.html index eefcb10e1d..988fa82072 100644 --- a/docs/dyn/bigtableadmin_v2.projects.instances.tables.html +++ b/docs/dyn/bigtableadmin_v2.projects.instances.tables.html @@ -139,6 +139,10 @@

Method Details

{ # Request message for google.bigtable.admin.v2.BigtableTableAdmin.CheckConsistency "consistencyToken": "A String", # Required. The token created using GenerateConsistencyToken for the Table. + "dataBoostReadLocalWrites": { # Checks that all writes before the consistency token was generated in the same cluster are readable by Databoost. # Checks that reads using an app profile with `DataBoostIsolationReadOnly` can see all writes committed before the token was created, but only if the read and write target the same cluster. + }, + "standardReadRemoteWrites": { # Checks that all writes before the consistency token was generated are replicated in every cluster and readable. # Checks that reads using an app profile with `StandardIsolation` can see all writes committed before the token was created, even if the read and write target different clusters. + }, } x__xgafv: string, V1 error format. @@ -223,6 +227,32 @@

Method Details

"averageColumnsPerRow": 3.14, # How many column qualifiers are present in this column family, averaged over all rows in the table. e.g. For column family "family" in a table with 3 rows: * A row with cells in "family:col" and "other:col" (1 column in "family") * A row with cells in "family:col", "family:other_col", and "other:data" (2 columns in "family") * A row with cells in "other:col" (0 columns in "family", "family" not present) would report (1 + 2 + 0)/3 = 1.5 in this field. "logicalDataBytes": "A String", # How much space the data in the column family occupies. This is roughly how many bytes would be needed to read the contents of the entire column family (e.g. by streaming all contents out). }, + "valueType": { # `Type` represents the type of data that is written to, read from, or stored in 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. This might involve composing a series of steps into an "encoding chain," for example to convert from INT64 -> STRING -> raw bytes. In most cases, a "link" in the encoding chain will be based an on existing GoogleSQL conversion function like `CAST`. 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? # The type of data stored in each of this family's cell values, including its full encoding. If omitted, the family only serves raw untyped bytes. For now, only the `Aggregate` type is supported. `Aggregate` can only be set at family creation and is immutable afterwards. If `value_type` is `Aggregate`, written data must be compatible with: * `value_type.input_type` for `AddInput` mutations + "aggregateType": { # 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` . # Aggregate + "inputType": # Object with schema name: Type # Type of the inputs that are accumulated by this `Aggregate`, which must specify a full encoding. Use `AddInput` mutations to accumulate new inputs. + "stateType": # Object with schema name: Type # Output only. Type that holds the internal accumulator state for the `Aggregate`. This is a function of the `input_type` and `aggregator` chosen, and will always specify a full encoding. + "sum": { # Computes the sum of the input values. Allowed input: `Int64` State: same as input # Sum aggregator. + }, + }, + "bytesType": { # Bytes Values of type `Bytes` are stored in `Value.bytes_value`. # Bytes + "encoding": { # Rules used to convert to/from lower level types. # The encoding to use when converting to/from lower level types. + "raw": { # Leaves the value "as-is" * Natural sort? Yes * Self-delimiting? No * Compatibility? N/A # Use `Raw` encoding. + }, + }, + }, + "int64Type": { # Int64 Values of type `Int64` are stored in `Value.int_value`. # Int64 + "encoding": { # Rules used to convert to/from lower level types. # The encoding to use when converting to/from lower level types. + "bigEndianBytes": { # Encodes the value as an 8-byte big endian twos complement `Bytes` value. * Natural sort? No (positive values only) * Self-delimiting? Yes * Compatibility? - BigQuery Federation `BINARY` encoding - HBase `Bytes.toBytes` - Java `ByteBuffer.putLong()` with `ByteOrder.BIG_ENDIAN` # Use `BigEndianBytes` encoding. + "bytesType": { # Bytes Values of type `Bytes` are stored in `Value.bytes_value`. # The underlying `Bytes` type, which may be able to encode further. + "encoding": { # Rules used to convert to/from lower level types. # The encoding to use when converting to/from lower level types. + "raw": { # Leaves the value "as-is" * Natural sort? Yes * Self-delimiting? No * Compatibility? N/A # Use `Raw` encoding. + }, + }, + }, + }, + }, + }, + }, }, }, "deletionProtection": True or False, # Set to true to make the table protected against data loss. i.e. deleting the following resources through Admin APIs are prohibited: * The table. * The column families in the table. * The instance containing the table. Note one can still delete the data stored in the table through Data APIs. @@ -305,6 +335,32 @@

Method Details

"averageColumnsPerRow": 3.14, # How many column qualifiers are present in this column family, averaged over all rows in the table. e.g. For column family "family" in a table with 3 rows: * A row with cells in "family:col" and "other:col" (1 column in "family") * A row with cells in "family:col", "family:other_col", and "other:data" (2 columns in "family") * A row with cells in "other:col" (0 columns in "family", "family" not present) would report (1 + 2 + 0)/3 = 1.5 in this field. "logicalDataBytes": "A String", # How much space the data in the column family occupies. This is roughly how many bytes would be needed to read the contents of the entire column family (e.g. by streaming all contents out). }, + "valueType": { # `Type` represents the type of data that is written to, read from, or stored in 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. This might involve composing a series of steps into an "encoding chain," for example to convert from INT64 -> STRING -> raw bytes. In most cases, a "link" in the encoding chain will be based an on existing GoogleSQL conversion function like `CAST`. 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? # The type of data stored in each of this family's cell values, including its full encoding. If omitted, the family only serves raw untyped bytes. For now, only the `Aggregate` type is supported. `Aggregate` can only be set at family creation and is immutable afterwards. If `value_type` is `Aggregate`, written data must be compatible with: * `value_type.input_type` for `AddInput` mutations + "aggregateType": { # 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` . # Aggregate + "inputType": # Object with schema name: Type # Type of the inputs that are accumulated by this `Aggregate`, which must specify a full encoding. Use `AddInput` mutations to accumulate new inputs. + "stateType": # Object with schema name: Type # Output only. Type that holds the internal accumulator state for the `Aggregate`. This is a function of the `input_type` and `aggregator` chosen, and will always specify a full encoding. + "sum": { # Computes the sum of the input values. Allowed input: `Int64` State: same as input # Sum aggregator. + }, + }, + "bytesType": { # Bytes Values of type `Bytes` are stored in `Value.bytes_value`. # Bytes + "encoding": { # Rules used to convert to/from lower level types. # The encoding to use when converting to/from lower level types. + "raw": { # Leaves the value "as-is" * Natural sort? Yes * Self-delimiting? No * Compatibility? N/A # Use `Raw` encoding. + }, + }, + }, + "int64Type": { # Int64 Values of type `Int64` are stored in `Value.int_value`. # Int64 + "encoding": { # Rules used to convert to/from lower level types. # The encoding to use when converting to/from lower level types. + "bigEndianBytes": { # Encodes the value as an 8-byte big endian twos complement `Bytes` value. * Natural sort? No (positive values only) * Self-delimiting? Yes * Compatibility? - BigQuery Federation `BINARY` encoding - HBase `Bytes.toBytes` - Java `ByteBuffer.putLong()` with `ByteOrder.BIG_ENDIAN` # Use `BigEndianBytes` encoding. + "bytesType": { # Bytes Values of type `Bytes` are stored in `Value.bytes_value`. # The underlying `Bytes` type, which may be able to encode further. + "encoding": { # Rules used to convert to/from lower level types. # The encoding to use when converting to/from lower level types. + "raw": { # Leaves the value "as-is" * Natural sort? Yes * Self-delimiting? No * Compatibility? N/A # Use `Raw` encoding. + }, + }, + }, + }, + }, + }, + }, }, }, "deletionProtection": True or False, # Set to true to make the table protected against data loss. i.e. deleting the following resources through Admin APIs are prohibited: * The table. * The column families in the table. * The instance containing the table. Note one can still delete the data stored in the table through Data APIs. @@ -470,6 +526,32 @@

Method Details

"averageColumnsPerRow": 3.14, # How many column qualifiers are present in this column family, averaged over all rows in the table. e.g. For column family "family" in a table with 3 rows: * A row with cells in "family:col" and "other:col" (1 column in "family") * A row with cells in "family:col", "family:other_col", and "other:data" (2 columns in "family") * A row with cells in "other:col" (0 columns in "family", "family" not present) would report (1 + 2 + 0)/3 = 1.5 in this field. "logicalDataBytes": "A String", # How much space the data in the column family occupies. This is roughly how many bytes would be needed to read the contents of the entire column family (e.g. by streaming all contents out). }, + "valueType": { # `Type` represents the type of data that is written to, read from, or stored in 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. This might involve composing a series of steps into an "encoding chain," for example to convert from INT64 -> STRING -> raw bytes. In most cases, a "link" in the encoding chain will be based an on existing GoogleSQL conversion function like `CAST`. 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? # The type of data stored in each of this family's cell values, including its full encoding. If omitted, the family only serves raw untyped bytes. For now, only the `Aggregate` type is supported. `Aggregate` can only be set at family creation and is immutable afterwards. If `value_type` is `Aggregate`, written data must be compatible with: * `value_type.input_type` for `AddInput` mutations + "aggregateType": { # 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` . # Aggregate + "inputType": # Object with schema name: Type # Type of the inputs that are accumulated by this `Aggregate`, which must specify a full encoding. Use `AddInput` mutations to accumulate new inputs. + "stateType": # Object with schema name: Type # Output only. Type that holds the internal accumulator state for the `Aggregate`. This is a function of the `input_type` and `aggregator` chosen, and will always specify a full encoding. + "sum": { # Computes the sum of the input values. Allowed input: `Int64` State: same as input # Sum aggregator. + }, + }, + "bytesType": { # Bytes Values of type `Bytes` are stored in `Value.bytes_value`. # Bytes + "encoding": { # Rules used to convert to/from lower level types. # The encoding to use when converting to/from lower level types. + "raw": { # Leaves the value "as-is" * Natural sort? Yes * Self-delimiting? No * Compatibility? N/A # Use `Raw` encoding. + }, + }, + }, + "int64Type": { # Int64 Values of type `Int64` are stored in `Value.int_value`. # Int64 + "encoding": { # Rules used to convert to/from lower level types. # The encoding to use when converting to/from lower level types. + "bigEndianBytes": { # Encodes the value as an 8-byte big endian twos complement `Bytes` value. * Natural sort? No (positive values only) * Self-delimiting? Yes * Compatibility? - BigQuery Federation `BINARY` encoding - HBase `Bytes.toBytes` - Java `ByteBuffer.putLong()` with `ByteOrder.BIG_ENDIAN` # Use `BigEndianBytes` encoding. + "bytesType": { # Bytes Values of type `Bytes` are stored in `Value.bytes_value`. # The underlying `Bytes` type, which may be able to encode further. + "encoding": { # Rules used to convert to/from lower level types. # The encoding to use when converting to/from lower level types. + "raw": { # Leaves the value "as-is" * Natural sort? Yes * Self-delimiting? No * Compatibility? N/A # Use `Raw` encoding. + }, + }, + }, + }, + }, + }, + }, }, }, "deletionProtection": True or False, # Set to true to make the table protected against data loss. i.e. deleting the following resources through Admin APIs are prohibited: * The table. * The column families in the table. * The instance containing the table. Note one can still delete the data stored in the table through Data APIs. @@ -627,6 +709,32 @@

Method Details

"averageColumnsPerRow": 3.14, # How many column qualifiers are present in this column family, averaged over all rows in the table. e.g. For column family "family" in a table with 3 rows: * A row with cells in "family:col" and "other:col" (1 column in "family") * A row with cells in "family:col", "family:other_col", and "other:data" (2 columns in "family") * A row with cells in "other:col" (0 columns in "family", "family" not present) would report (1 + 2 + 0)/3 = 1.5 in this field. "logicalDataBytes": "A String", # How much space the data in the column family occupies. This is roughly how many bytes would be needed to read the contents of the entire column family (e.g. by streaming all contents out). }, + "valueType": { # `Type` represents the type of data that is written to, read from, or stored in 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. This might involve composing a series of steps into an "encoding chain," for example to convert from INT64 -> STRING -> raw bytes. In most cases, a "link" in the encoding chain will be based an on existing GoogleSQL conversion function like `CAST`. 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? # The type of data stored in each of this family's cell values, including its full encoding. If omitted, the family only serves raw untyped bytes. For now, only the `Aggregate` type is supported. `Aggregate` can only be set at family creation and is immutable afterwards. If `value_type` is `Aggregate`, written data must be compatible with: * `value_type.input_type` for `AddInput` mutations + "aggregateType": { # 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` . # Aggregate + "inputType": # Object with schema name: Type # Type of the inputs that are accumulated by this `Aggregate`, which must specify a full encoding. Use `AddInput` mutations to accumulate new inputs. + "stateType": # Object with schema name: Type # Output only. Type that holds the internal accumulator state for the `Aggregate`. This is a function of the `input_type` and `aggregator` chosen, and will always specify a full encoding. + "sum": { # Computes the sum of the input values. Allowed input: `Int64` State: same as input # Sum aggregator. + }, + }, + "bytesType": { # Bytes Values of type `Bytes` are stored in `Value.bytes_value`. # Bytes + "encoding": { # Rules used to convert to/from lower level types. # The encoding to use when converting to/from lower level types. + "raw": { # Leaves the value "as-is" * Natural sort? Yes * Self-delimiting? No * Compatibility? N/A # Use `Raw` encoding. + }, + }, + }, + "int64Type": { # Int64 Values of type `Int64` are stored in `Value.int_value`. # Int64 + "encoding": { # Rules used to convert to/from lower level types. # The encoding to use when converting to/from lower level types. + "bigEndianBytes": { # Encodes the value as an 8-byte big endian twos complement `Bytes` value. * Natural sort? No (positive values only) * Self-delimiting? Yes * Compatibility? - BigQuery Federation `BINARY` encoding - HBase `Bytes.toBytes` - Java `ByteBuffer.putLong()` with `ByteOrder.BIG_ENDIAN` # Use `BigEndianBytes` encoding. + "bytesType": { # Bytes Values of type `Bytes` are stored in `Value.bytes_value`. # The underlying `Bytes` type, which may be able to encode further. + "encoding": { # Rules used to convert to/from lower level types. # The encoding to use when converting to/from lower level types. + "raw": { # Leaves the value "as-is" * Natural sort? Yes * Self-delimiting? No * Compatibility? N/A # Use `Raw` encoding. + }, + }, + }, + }, + }, + }, + }, }, }, "deletionProtection": True or False, # Set to true to make the table protected against data loss. i.e. deleting the following resources through Admin APIs are prohibited: * The table. * The column families in the table. * The instance containing the table. Note one can still delete the data stored in the table through Data APIs. @@ -700,6 +808,32 @@

Method Details

"averageColumnsPerRow": 3.14, # How many column qualifiers are present in this column family, averaged over all rows in the table. e.g. For column family "family" in a table with 3 rows: * A row with cells in "family:col" and "other:col" (1 column in "family") * A row with cells in "family:col", "family:other_col", and "other:data" (2 columns in "family") * A row with cells in "other:col" (0 columns in "family", "family" not present) would report (1 + 2 + 0)/3 = 1.5 in this field. "logicalDataBytes": "A String", # How much space the data in the column family occupies. This is roughly how many bytes would be needed to read the contents of the entire column family (e.g. by streaming all contents out). }, + "valueType": { # `Type` represents the type of data that is written to, read from, or stored in 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. This might involve composing a series of steps into an "encoding chain," for example to convert from INT64 -> STRING -> raw bytes. In most cases, a "link" in the encoding chain will be based an on existing GoogleSQL conversion function like `CAST`. 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? # The type of data stored in each of this family's cell values, including its full encoding. If omitted, the family only serves raw untyped bytes. For now, only the `Aggregate` type is supported. `Aggregate` can only be set at family creation and is immutable afterwards. If `value_type` is `Aggregate`, written data must be compatible with: * `value_type.input_type` for `AddInput` mutations + "aggregateType": { # 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` . # Aggregate + "inputType": # Object with schema name: Type # Type of the inputs that are accumulated by this `Aggregate`, which must specify a full encoding. Use `AddInput` mutations to accumulate new inputs. + "stateType": # Object with schema name: Type # Output only. Type that holds the internal accumulator state for the `Aggregate`. This is a function of the `input_type` and `aggregator` chosen, and will always specify a full encoding. + "sum": { # Computes the sum of the input values. Allowed input: `Int64` State: same as input # Sum aggregator. + }, + }, + "bytesType": { # Bytes Values of type `Bytes` are stored in `Value.bytes_value`. # Bytes + "encoding": { # Rules used to convert to/from lower level types. # The encoding to use when converting to/from lower level types. + "raw": { # Leaves the value "as-is" * Natural sort? Yes * Self-delimiting? No * Compatibility? N/A # Use `Raw` encoding. + }, + }, + }, + "int64Type": { # Int64 Values of type `Int64` are stored in `Value.int_value`. # Int64 + "encoding": { # Rules used to convert to/from lower level types. # The encoding to use when converting to/from lower level types. + "bigEndianBytes": { # Encodes the value as an 8-byte big endian twos complement `Bytes` value. * Natural sort? No (positive values only) * Self-delimiting? Yes * Compatibility? - BigQuery Federation `BINARY` encoding - HBase `Bytes.toBytes` - Java `ByteBuffer.putLong()` with `ByteOrder.BIG_ENDIAN` # Use `BigEndianBytes` encoding. + "bytesType": { # Bytes Values of type `Bytes` are stored in `Value.bytes_value`. # The underlying `Bytes` type, which may be able to encode further. + "encoding": { # Rules used to convert to/from lower level types. # The encoding to use when converting to/from lower level types. + "raw": { # Leaves the value "as-is" * Natural sort? Yes * Self-delimiting? No * Compatibility? N/A # Use `Raw` encoding. + }, + }, + }, + }, + }, + }, + }, }, "drop": True or False, # Drop (delete) the column family with the given ID, or fail if no such family exists. "id": "A String", # The ID of the column family to be modified. @@ -723,6 +857,32 @@

Method Details

"averageColumnsPerRow": 3.14, # How many column qualifiers are present in this column family, averaged over all rows in the table. e.g. For column family "family" in a table with 3 rows: * A row with cells in "family:col" and "other:col" (1 column in "family") * A row with cells in "family:col", "family:other_col", and "other:data" (2 columns in "family") * A row with cells in "other:col" (0 columns in "family", "family" not present) would report (1 + 2 + 0)/3 = 1.5 in this field. "logicalDataBytes": "A String", # How much space the data in the column family occupies. This is roughly how many bytes would be needed to read the contents of the entire column family (e.g. by streaming all contents out). }, + "valueType": { # `Type` represents the type of data that is written to, read from, or stored in 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. This might involve composing a series of steps into an "encoding chain," for example to convert from INT64 -> STRING -> raw bytes. In most cases, a "link" in the encoding chain will be based an on existing GoogleSQL conversion function like `CAST`. 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? # The type of data stored in each of this family's cell values, including its full encoding. If omitted, the family only serves raw untyped bytes. For now, only the `Aggregate` type is supported. `Aggregate` can only be set at family creation and is immutable afterwards. If `value_type` is `Aggregate`, written data must be compatible with: * `value_type.input_type` for `AddInput` mutations + "aggregateType": { # 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` . # Aggregate + "inputType": # Object with schema name: Type # Type of the inputs that are accumulated by this `Aggregate`, which must specify a full encoding. Use `AddInput` mutations to accumulate new inputs. + "stateType": # Object with schema name: Type # Output only. Type that holds the internal accumulator state for the `Aggregate`. This is a function of the `input_type` and `aggregator` chosen, and will always specify a full encoding. + "sum": { # Computes the sum of the input values. Allowed input: `Int64` State: same as input # Sum aggregator. + }, + }, + "bytesType": { # Bytes Values of type `Bytes` are stored in `Value.bytes_value`. # Bytes + "encoding": { # Rules used to convert to/from lower level types. # The encoding to use when converting to/from lower level types. + "raw": { # Leaves the value "as-is" * Natural sort? Yes * Self-delimiting? No * Compatibility? N/A # Use `Raw` encoding. + }, + }, + }, + "int64Type": { # Int64 Values of type `Int64` are stored in `Value.int_value`. # Int64 + "encoding": { # Rules used to convert to/from lower level types. # The encoding to use when converting to/from lower level types. + "bigEndianBytes": { # Encodes the value as an 8-byte big endian twos complement `Bytes` value. * Natural sort? No (positive values only) * Self-delimiting? Yes * Compatibility? - BigQuery Federation `BINARY` encoding - HBase `Bytes.toBytes` - Java `ByteBuffer.putLong()` with `ByteOrder.BIG_ENDIAN` # Use `BigEndianBytes` encoding. + "bytesType": { # Bytes Values of type `Bytes` are stored in `Value.bytes_value`. # The underlying `Bytes` type, which may be able to encode further. + "encoding": { # Rules used to convert to/from lower level types. # The encoding to use when converting to/from lower level types. + "raw": { # Leaves the value "as-is" * Natural sort? Yes * Self-delimiting? No * Compatibility? N/A # Use `Raw` encoding. + }, + }, + }, + }, + }, + }, + }, }, "updateMask": "A String", # Optional. A mask specifying which fields (e.g. `gc_rule`) in the `update` mod should be updated, ignored for other modification types. If unset or empty, we treat it as updating `gc_rule` to be backward compatible. }, @@ -786,6 +946,32 @@

Method Details

"averageColumnsPerRow": 3.14, # How many column qualifiers are present in this column family, averaged over all rows in the table. e.g. For column family "family" in a table with 3 rows: * A row with cells in "family:col" and "other:col" (1 column in "family") * A row with cells in "family:col", "family:other_col", and "other:data" (2 columns in "family") * A row with cells in "other:col" (0 columns in "family", "family" not present) would report (1 + 2 + 0)/3 = 1.5 in this field. "logicalDataBytes": "A String", # How much space the data in the column family occupies. This is roughly how many bytes would be needed to read the contents of the entire column family (e.g. by streaming all contents out). }, + "valueType": { # `Type` represents the type of data that is written to, read from, or stored in 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. This might involve composing a series of steps into an "encoding chain," for example to convert from INT64 -> STRING -> raw bytes. In most cases, a "link" in the encoding chain will be based an on existing GoogleSQL conversion function like `CAST`. 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? # The type of data stored in each of this family's cell values, including its full encoding. If omitted, the family only serves raw untyped bytes. For now, only the `Aggregate` type is supported. `Aggregate` can only be set at family creation and is immutable afterwards. If `value_type` is `Aggregate`, written data must be compatible with: * `value_type.input_type` for `AddInput` mutations + "aggregateType": { # 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` . # Aggregate + "inputType": # Object with schema name: Type # Type of the inputs that are accumulated by this `Aggregate`, which must specify a full encoding. Use `AddInput` mutations to accumulate new inputs. + "stateType": # Object with schema name: Type # Output only. Type that holds the internal accumulator state for the `Aggregate`. This is a function of the `input_type` and `aggregator` chosen, and will always specify a full encoding. + "sum": { # Computes the sum of the input values. Allowed input: `Int64` State: same as input # Sum aggregator. + }, + }, + "bytesType": { # Bytes Values of type `Bytes` are stored in `Value.bytes_value`. # Bytes + "encoding": { # Rules used to convert to/from lower level types. # The encoding to use when converting to/from lower level types. + "raw": { # Leaves the value "as-is" * Natural sort? Yes * Self-delimiting? No * Compatibility? N/A # Use `Raw` encoding. + }, + }, + }, + "int64Type": { # Int64 Values of type `Int64` are stored in `Value.int_value`. # Int64 + "encoding": { # Rules used to convert to/from lower level types. # The encoding to use when converting to/from lower level types. + "bigEndianBytes": { # Encodes the value as an 8-byte big endian twos complement `Bytes` value. * Natural sort? No (positive values only) * Self-delimiting? Yes * Compatibility? - BigQuery Federation `BINARY` encoding - HBase `Bytes.toBytes` - Java `ByteBuffer.putLong()` with `ByteOrder.BIG_ENDIAN` # Use `BigEndianBytes` encoding. + "bytesType": { # Bytes Values of type `Bytes` are stored in `Value.bytes_value`. # The underlying `Bytes` type, which may be able to encode further. + "encoding": { # Rules used to convert to/from lower level types. # The encoding to use when converting to/from lower level types. + "raw": { # Leaves the value "as-is" * Natural sort? Yes * Self-delimiting? No * Compatibility? N/A # Use `Raw` encoding. + }, + }, + }, + }, + }, + }, + }, }, }, "deletionProtection": True or False, # Set to true to make the table protected against data loss. i.e. deleting the following resources through Admin APIs are prohibited: * The table. * The column families in the table. * The instance containing the table. Note one can still delete the data stored in the table through Data APIs. @@ -868,6 +1054,32 @@

Method Details

"averageColumnsPerRow": 3.14, # How many column qualifiers are present in this column family, averaged over all rows in the table. e.g. For column family "family" in a table with 3 rows: * A row with cells in "family:col" and "other:col" (1 column in "family") * A row with cells in "family:col", "family:other_col", and "other:data" (2 columns in "family") * A row with cells in "other:col" (0 columns in "family", "family" not present) would report (1 + 2 + 0)/3 = 1.5 in this field. "logicalDataBytes": "A String", # How much space the data in the column family occupies. This is roughly how many bytes would be needed to read the contents of the entire column family (e.g. by streaming all contents out). }, + "valueType": { # `Type` represents the type of data that is written to, read from, or stored in 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. This might involve composing a series of steps into an "encoding chain," for example to convert from INT64 -> STRING -> raw bytes. In most cases, a "link" in the encoding chain will be based an on existing GoogleSQL conversion function like `CAST`. 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? # The type of data stored in each of this family's cell values, including its full encoding. If omitted, the family only serves raw untyped bytes. For now, only the `Aggregate` type is supported. `Aggregate` can only be set at family creation and is immutable afterwards. If `value_type` is `Aggregate`, written data must be compatible with: * `value_type.input_type` for `AddInput` mutations + "aggregateType": { # 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` . # Aggregate + "inputType": # Object with schema name: Type # Type of the inputs that are accumulated by this `Aggregate`, which must specify a full encoding. Use `AddInput` mutations to accumulate new inputs. + "stateType": # Object with schema name: Type # Output only. Type that holds the internal accumulator state for the `Aggregate`. This is a function of the `input_type` and `aggregator` chosen, and will always specify a full encoding. + "sum": { # Computes the sum of the input values. Allowed input: `Int64` State: same as input # Sum aggregator. + }, + }, + "bytesType": { # Bytes Values of type `Bytes` are stored in `Value.bytes_value`. # Bytes + "encoding": { # Rules used to convert to/from lower level types. # The encoding to use when converting to/from lower level types. + "raw": { # Leaves the value "as-is" * Natural sort? Yes * Self-delimiting? No * Compatibility? N/A # Use `Raw` encoding. + }, + }, + }, + "int64Type": { # Int64 Values of type `Int64` are stored in `Value.int_value`. # Int64 + "encoding": { # Rules used to convert to/from lower level types. # The encoding to use when converting to/from lower level types. + "bigEndianBytes": { # Encodes the value as an 8-byte big endian twos complement `Bytes` value. * Natural sort? No (positive values only) * Self-delimiting? Yes * Compatibility? - BigQuery Federation `BINARY` encoding - HBase `Bytes.toBytes` - Java `ByteBuffer.putLong()` with `ByteOrder.BIG_ENDIAN` # Use `BigEndianBytes` encoding. + "bytesType": { # Bytes Values of type `Bytes` are stored in `Value.bytes_value`. # The underlying `Bytes` type, which may be able to encode further. + "encoding": { # Rules used to convert to/from lower level types. # The encoding to use when converting to/from lower level types. + "raw": { # Leaves the value "as-is" * Natural sort? Yes * Self-delimiting? No * Compatibility? N/A # Use `Raw` encoding. + }, + }, + }, + }, + }, + }, + }, }, }, "deletionProtection": True or False, # Set to true to make the table protected against data loss. i.e. deleting the following resources through Admin APIs are prohibited: * The table. * The column families in the table. * The instance containing the table. Note one can still delete the data stored in the table through Data APIs. diff --git a/googleapiclient/discovery_cache/documents/bigtableadmin.v2.json b/googleapiclient/discovery_cache/documents/bigtableadmin.v2.json index 6843349445..b3786345fa 100644 --- a/googleapiclient/discovery_cache/documents/bigtableadmin.v2.json +++ b/googleapiclient/discovery_cache/documents/bigtableadmin.v2.json @@ -2098,13 +2098,17 @@ } } }, -"revision": "20240306", +"revision": "20240318", "rootUrl": "https://bigtableadmin.googleapis.com/", "schemas": { "AppProfile": { "description": "A configuration object describing how Cloud Bigtable should treat traffic from a particular end user application.", "id": "AppProfile", "properties": { +"dataBoostIsolationReadOnly": { +"$ref": "DataBoostIsolationReadOnly", +"description": "Specifies that this app profile is intended for read-only usage via the Data Boost feature." +}, "description": { "description": "Long form description of the use case for this AppProfile.", "type": "string" @@ -2409,6 +2413,14 @@ "consistencyToken": { "description": "Required. The token created using GenerateConsistencyToken for the Table.", "type": "string" +}, +"dataBoostReadLocalWrites": { +"$ref": "DataBoostReadLocalWrites", +"description": "Checks that reads using an app profile with `DataBoostIsolationReadOnly` can see all writes committed before the token was created, but only if the read and write target the same cluster." +}, +"standardReadRemoteWrites": { +"$ref": "StandardReadRemoteWrites", +"description": "Checks that reads using an app profile with `StandardIsolation` can see all writes committed before the token was created, even if the read and write target different clusters." } }, "type": "object" @@ -2559,6 +2571,10 @@ "$ref": "ColumnFamilyStats", "description": "Output only. Only available with STATS_VIEW, this includes summary statistics about column family contents. For statistics over an entire table, see TableStats above.", "readOnly": true +}, +"valueType": { +"$ref": "Type", +"description": "The type of data stored in each of this family's cell values, including its full encoding. If omitted, the family only serves raw untyped bytes. For now, only the `Aggregate` type is supported. `Aggregate` can only be set at family creation and is immutable afterwards. If `value_type` is `Aggregate`, written data must be compatible with: * `value_type.input_type` for `AddInput` mutations" } }, "type": "object" @@ -2805,6 +2821,31 @@ }, "type": "object" }, +"DataBoostIsolationReadOnly": { +"description": "Data Boost is a serverless compute capability that lets you run high-throughput read jobs on your Bigtable data, without impacting the performance of the clusters that handle your application traffic. Currently, Data Boost exclusively supports read-only use-cases with single-cluster routing. Data Boost reads are only guaranteed to see the results of writes that were written at least 30 minutes ago. This means newly written values may not become visible for up to 30m, and also means that old values may remain visible for up to 30m after being deleted or overwritten. To mitigate the staleness of the data, users may either wait 30m, or use CheckConsistency.", +"id": "DataBoostIsolationReadOnly", +"properties": { +"computeBillingOwner": { +"description": "The Compute Billing Owner for this Data Boost App Profile.", +"enum": [ +"COMPUTE_BILLING_OWNER_UNSPECIFIED", +"HOST_PAYS" +], +"enumDescriptions": [ +"Unspecified value.", +"The host Cloud Project containing the targeted Bigtable Instance / Table pays for compute." +], +"type": "string" +} +}, +"type": "object" +}, +"DataBoostReadLocalWrites": { +"description": "Checks that all writes before the consistency token was generated in the same cluster are readable by Databoost.", +"id": "DataBoostReadLocalWrites", +"properties": {}, +"type": "object" +}, "DropRowRangeRequest": { "description": "Request message for google.bigtable.admin.v2.BigtableTableAdmin.DropRowRange", "id": "DropRowRangeRequest", @@ -3003,6 +3044,93 @@ }, "type": "object" }, +"GoogleBigtableAdminV2TypeAggregate": { +"description": "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` .", +"id": "GoogleBigtableAdminV2TypeAggregate", +"properties": { +"inputType": { +"$ref": "Type", +"description": "Type of the inputs that are accumulated by this `Aggregate`, which must specify a full encoding. Use `AddInput` mutations to accumulate new inputs." +}, +"stateType": { +"$ref": "Type", +"description": "Output only. Type that holds the internal accumulator state for the `Aggregate`. This is a function of the `input_type` and `aggregator` chosen, and will always specify a full encoding.", +"readOnly": true +}, +"sum": { +"$ref": "GoogleBigtableAdminV2TypeAggregateSum", +"description": "Sum aggregator." +} +}, +"type": "object" +}, +"GoogleBigtableAdminV2TypeAggregateSum": { +"description": "Computes the sum of the input values. Allowed input: `Int64` State: same as input", +"id": "GoogleBigtableAdminV2TypeAggregateSum", +"properties": {}, +"type": "object" +}, +"GoogleBigtableAdminV2TypeBytes": { +"description": "Bytes Values of type `Bytes` are stored in `Value.bytes_value`.", +"id": "GoogleBigtableAdminV2TypeBytes", +"properties": { +"encoding": { +"$ref": "GoogleBigtableAdminV2TypeBytesEncoding", +"description": "The encoding to use when converting to/from lower level types." +} +}, +"type": "object" +}, +"GoogleBigtableAdminV2TypeBytesEncoding": { +"description": "Rules used to convert to/from lower level types.", +"id": "GoogleBigtableAdminV2TypeBytesEncoding", +"properties": { +"raw": { +"$ref": "GoogleBigtableAdminV2TypeBytesEncodingRaw", +"description": "Use `Raw` encoding." +} +}, +"type": "object" +}, +"GoogleBigtableAdminV2TypeBytesEncodingRaw": { +"description": "Leaves the value \"as-is\" * Natural sort? Yes * Self-delimiting? No * Compatibility? N/A", +"id": "GoogleBigtableAdminV2TypeBytesEncodingRaw", +"properties": {}, +"type": "object" +}, +"GoogleBigtableAdminV2TypeInt64": { +"description": "Int64 Values of type `Int64` are stored in `Value.int_value`.", +"id": "GoogleBigtableAdminV2TypeInt64", +"properties": { +"encoding": { +"$ref": "GoogleBigtableAdminV2TypeInt64Encoding", +"description": "The encoding to use when converting to/from lower level types." +} +}, +"type": "object" +}, +"GoogleBigtableAdminV2TypeInt64Encoding": { +"description": "Rules used to convert to/from lower level types.", +"id": "GoogleBigtableAdminV2TypeInt64Encoding", +"properties": { +"bigEndianBytes": { +"$ref": "GoogleBigtableAdminV2TypeInt64EncodingBigEndianBytes", +"description": "Use `BigEndianBytes` encoding." +} +}, +"type": "object" +}, +"GoogleBigtableAdminV2TypeInt64EncodingBigEndianBytes": { +"description": "Encodes the value as an 8-byte big endian twos complement `Bytes` value. * Natural sort? No (positive values only) * Self-delimiting? Yes * Compatibility? - BigQuery Federation `BINARY` encoding - HBase `Bytes.toBytes` - Java `ByteBuffer.putLong()` with `ByteOrder.BIG_ENDIAN`", +"id": "GoogleBigtableAdminV2TypeInt64EncodingBigEndianBytes", +"properties": { +"bytesType": { +"$ref": "GoogleBigtableAdminV2TypeBytes", +"description": "The underlying `Bytes` type, which may be able to encode further." +} +}, +"type": "object" +}, "HotTablet": { "description": "A tablet is a defined by a start and end key and is explained in https://cloud.google.com/bigtable/docs/overview#architecture and https://cloud.google.com/bigtable/docs/performance#optimization. A Hot tablet is a tablet that exhibits high average cpu usage during the time interval from start time to end time.", "id": "HotTablet", @@ -3691,6 +3819,12 @@ }, "type": "object" }, +"StandardReadRemoteWrites": { +"description": "Checks that all writes before the consistency token was generated are replicated in every cluster and readable.", +"id": "StandardReadRemoteWrites", +"properties": {}, +"type": "object" +}, "Status": { "description": "The `Status` type defines a logical error model that is suitable for different programming environments, including REST APIs and RPC APIs. It is used by [gRPC](https://github.com/grpc). Each `Status` message contains three pieces of data: error code, error message, and error details. You can find out more about this error model and how to work with it in the [API Design Guide](https://cloud.google.com/apis/design/errors).", "id": "Status", @@ -3867,6 +4001,25 @@ }, "type": "object" }, +"Type": { +"description": "`Type` represents the type of data that is written to, read from, or stored in 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. This might involve composing a series of steps into an \"encoding chain,\" for example to convert from INT64 -> STRING -> raw bytes. In most cases, a \"link\" in the encoding chain will be based an on existing GoogleSQL conversion function like `CAST`. 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?", +"id": "Type", +"properties": { +"aggregateType": { +"$ref": "GoogleBigtableAdminV2TypeAggregate", +"description": "Aggregate" +}, +"bytesType": { +"$ref": "GoogleBigtableAdminV2TypeBytes", +"description": "Bytes" +}, +"int64Type": { +"$ref": "GoogleBigtableAdminV2TypeInt64", +"description": "Int64" +} +}, +"type": "object" +}, "UndeleteTableMetadata": { "description": "Metadata type for the operation returned by google.bigtable.admin.v2.BigtableTableAdmin.UndeleteTable.", "id": "UndeleteTableMetadata",