Google Bigtable v2 API - Class Cell (3.12.0)

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

Reference 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.

Inheritance

object > Cell

Implements

IMessage Cell, IEquatable Cell, IDeepCloneable Cell, IBufferMessage, IMessage

Inherited Members

object.GetHashCode()

object.GetType()

object.ToString()

Namespace

Google.Cloud.Bigtable.V2

Assembly

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`

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.