Hi there! Are you looking for the official Deno documentation? Try docs.deno.com for all your Deno learning needs.

Table

import type { Table } from "https://googleapis.deno.dev/v1/bigtableadmin:v2.ts";

A collection of user data indexed by row, column, and timestamp. Each table is served using the resources of its parent cluster.

interface Table {
automatedBackupPolicy?: AutomatedBackupPolicy;
changeStreamConfig?: ChangeStreamConfig;
readonly clusterStates?: {
[key: string]: ClusterState;
}
;
columnFamilies?: {
[key: string]: ColumnFamily;
}
;
deletionProtection?: boolean;
granularity?: "TIMESTAMP_GRANULARITY_UNSPECIFIED" | "MILLIS";
name?: string;
readonly restoreInfo?: RestoreInfo;
readonly stats?: TableStats;
tieredStorageConfig?: TieredStorageConfig;
}

§Properties

§
automatedBackupPolicy?: AutomatedBackupPolicy
[src]

If specified, automated backups are enabled for this table. Otherwise, automated backups are disabled.

§
changeStreamConfig?: ChangeStreamConfig
[src]

If specified, enable the change stream on this table. Otherwise, the change stream is disabled and the change stream is not retained.

§
readonly clusterStates?: {
[key: string]: ClusterState;
}
[src]

Output only. Map from cluster ID to per-cluster table state. If it could not be determined whether or not the table has data in a particular cluster (for example, if its zone is unavailable), then there will be an entry for the cluster with UNKNOWN replication_status. Views: REPLICATION_VIEW, ENCRYPTION_VIEW, FULL

§
columnFamilies?: {
[key: string]: ColumnFamily;
}
[src]

The column families configured for this table, mapped by column family ID. Views: SCHEMA_VIEW, STATS_VIEW, FULL

§
deletionProtection?: boolean
[src]

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.

§
granularity?: "TIMESTAMP_GRANULARITY_UNSPECIFIED" | "MILLIS"
[src]

Immutable. The granularity (i.e. MILLIS) at which timestamps are stored in this table. Timestamps not matching the granularity will be rejected. If unspecified at creation time, the value will be set to MILLIS. Views: SCHEMA_VIEW, FULL.

§
name?: string
[src]

The unique name of the table. Values are of the form projects/{project}/instances/{instance}/tables/_a-zA-Z0-9*. Views: NAME_ONLY, SCHEMA_VIEW, REPLICATION_VIEW, STATS_VIEW, FULL

§
readonly restoreInfo?: RestoreInfo
[src]

Output only. If this table was restored from another data source (e.g. a backup), this field will be populated with information about the restore.

§

The row key schema for this table. The schema is used to decode the raw row key bytes into a structured format. The order of field declarations in this schema is important, as it reflects how the raw row key bytes are structured. Currently, this only affects how the key is read via a GoogleSQL query from the ExecuteQuery API. For a SQL query, the _key column is still read as raw bytes. But queries can reference the key fields by name, which will be decoded from _key using provided type and encoding. Queries that reference key fields will fail if they encounter an invalid row key. For example, if _key = "some_id#2024-04-30#\x00\x13\x00\xf3" with the following schema: { fields { field_name: "id" type { string { encoding: utf8_bytes {} } } } fields { field_name: "date" type { string { encoding: utf8_bytes {} } } } fields { field_name: "product_code" type { int64 { encoding: big_endian_bytes {} } } } encoding { delimited_bytes { delimiter: "#" } } } The decoded key parts would be: id = "some_id", date = "2024-04-30", product_code = 1245427 The query "SELECT _key, product_code FROM table" will return two columns: /------------------------------------------------------\ | _key | product_code | | --------------------------------------|--------------| | "some_id#2024-04-30#\x00\x13\x00\xf3" | 1245427 | ------------------------------------------------------/ The schema has the following invariants: (1) The decoded field values are order-preserved. For read, the field values will be decoded in sorted mode from the raw bytes. (2) Every field in the schema must specify a non-empty name. (3) Every field must specify a type with an associated encoding. The type is limited to scalar types only: Array, Map, Aggregate, and Struct are not allowed. (4) The field names must not collide with existing column family names and reserved keywords "_key" and "_timestamp". The following update operations are allowed for row_key_schema: - Update from an empty schema to a new schema. - Remove the existing schema. This operation requires setting the ignore_warnings flag to true, since it might be a backward incompatible change. Without the flag, the update request will fail with an INVALID_ARGUMENT error. Any other row key schema update operation (e.g. update existing schema columns names or types) is currently unsupported.

§
readonly stats?: TableStats
[src]

Output only. Only available with STATS_VIEW, this includes summary statistics about the entire table contents. For statistics about a specific column family, see ColumnFamilyStats in the mapped ColumnFamily collection above.

§
tieredStorageConfig?: TieredStorageConfig
[src]

Rules to specify what data is stored in each storage tier. Different tiers store data differently, providing different trade-offs between cost and performance. Different parts of a table can be stored separately on different tiers. If a config is specified, tiered storage is enabled for this table. Otherwise, tiered storage is disabled. Only SSD instances can configure tiered storage.