Class Cell (2.6.0)

public sealed class Cell : IMessage<Cell>, IEquatable<Cell>, IDeepCloneable<Cell>, IBufferMessage, IMessage

Specifies (some of) the contents of a single row/column/timestamp of a table.

Inheritance

Object > Cell

Namespace

Google.Cloud.Bigtable.V2

Assembly

Google.Cloud.Bigtable.V2.dll

Constructors

Cell()

public Cell()

Cell(Cell)

public Cell(Cell other)
Parameter
NameDescription
otherCell

Properties

Labels

public RepeatedField<string> Labels { get; }

Labels applied to the cell by a [RowFilter][google.bigtable.v2.RowFilter].

Property Value
TypeDescription
RepeatedField<String>

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
TypeDescription
Int64

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
TypeDescription
ByteString

Version

public BigtableVersion Version { get; }

Gets the version of the cell, which uniquely identifies it within its column.

Property Value
TypeDescription
BigtableVersion
Remarks

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.