public sealed class Cell : IMessage<Cell>, IEquatable<Cell>, IDeepCloneable<Cell>, IBufferMessage, IMessageReference documentation and code samples for the Google Bigtable v2 API class Cell.
Specifies (some of) the contents of a single row/column/timestamp of a table.
Namespace
GoogleGoogle.CloudGoogle.Cloud.BigtableV2Assembly
Google.Cloud.Bigtable.V2.dll
Constructors
Cell()
public Cell()Cell(Cell)
public Cell(Cell other)| Parameter | |
|---|---|
| Name | Description |
other | Cell |
Properties
Labels
public RepeatedField<string> Labels { get; }Labels applied to the cell by a [RowFilter][google.bigtable.v2.RowFilter].
| Property Value | |
|---|---|
| Type | Description |
RepeatedFieldstring | |
TimestampMicros
public long TimestampMicros { get; set; }The cell's stored timestamp, which also uniquely identifies it within
its column.
Values are always expressed in microseconds, but individual tables may set
a coarser granularity to further restrict the allowed values. For
example, a table which specifies millisecond granularity will only allow
values of timestamp_micros which are multiples of 1000.
| Property Value | |
|---|---|
| Type | Description |
long | |
Value
public ByteString Value { get; set; }The value stored in the cell. May contain any byte string, including the empty string, up to 100MiB in length.
| Property Value | |
|---|---|
| Type | Description |
ByteString | |
Version
public BigtableVersion Version { get; }Gets the version of the cell, which uniquely identifies it within its column.
| Property Value | |
|---|---|
| Type | Description |
BigtableVersion | |
Note: version values are stored on the server as if they are microseconds since the Unix epoch. However, the server only supports millisecond granularity, so the server only allows microseconds in multiples of 1,000. BigtableVersion attempts to hide this complexity by exposing its underlying Value in terms of milliseconds, so if desired, a custom versioning scheme of 1, 2, ... can be used rather than 1000, 2000, ... However, access to the underlying microsecond value is still provided via Micros.
Note: when using ReadModifyWriteRow, modified columns automatically use a server version, which is based on the current timestamp since the Unix epoch. For those columns, other reads and writes should use BigtableVersion values constructed from DateTime values, as opposed to using a custom versioning scheme with 64-bit values.