Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

A value area contains data for each tuple field one after another as described above. Potentially a field can contain any kind of data.  However there are rules for representation of common data types there. These rules are specified in the following section. Data types for which there are no specified rules still may be put into a tuple as a Binary field, but the interpretation in such cases is fully up to a particular application.

Field

...

The list of supported data types is as follows:

...

Encoding

A tuple field is a sequence of bytes. This sequence is interpreted according to the associated data type provided by the tuple schema. There are different encoding rules for different values. The rules include a simple compression mechanism. So even if the original type has some fixed size when it is encoded as a tuple field it may occupy variable number of bytes.

...

Int32

...

Fixed-size values are stored in little-endian byte order. If a value is equal to NULL then it is absent in the value area. This means that in the offset table the corresponding entry is equal to the previous entry. At the same time the corresponding bit in the nullmap is set.

Hence for For any variable-length field as we find its length from the offset table we can encounter the case when the length is equal to zero. At this point the value has to be disambiguated in this way:type we can encounter a value with zero length. Again the length is determined by the offset table. Quite naturally a zero-length variable-length value translates to a zero-length field in a tuple. This approach is extended to fixed-size types by introducing a notion of default values. We define specific default values for different types (specified in the table below). If a given value is equal to the corresponding default value then this translates to a zero-length field in a tuple.

To sum things up, when a zero-length field is met (by looking in the offset table) we have the following cases:

  1. If the corresponding nullmap bit is set then this is a NULL value;
  2. If the corresponding nullmap bit is clear and
    1. if the corresponding type is variable-length then this is a zero-length (empty) value;
    If
    1. if the corresponding
    nullmap bit is set
    1. type is fixed-size then this is a
    NULL
    1. default value.

This approach is naturally extended to fixed-size fields. But instead of a zero-length value we interpret it as a value of zero. More specifically:

...

The list of supported data types is as follows:

TypeSizeDefault ValueDescription
Int810
Int161-20

Int32

1-40
Int641-80
Float40.0
Double4, 80.0
Numbervariable0
Decimalvariable0
UUID16

...

00000000-0000-0000-0000-000000000000

...


Stringvariableempty string
Binaryvariableempty binary
Bitmaskvariableempty bit-string
Date3

Jan 1, 1 BC for date (1 BC immediately

precedes 1 AD in the Gregorian calendar)


Time4-600:00:00.000000

...


DateTime7-9Jan 1, 1 BC,

...

00:00:00.000000

...



Timestamp8, 12Jan 1,

...

1970 00:00:00.000000
Duration8, 12
0 (PT0S)

...


Period3, 6, 120 (P0D)

...


Boolean1false

Integer Field Compression

All integer values are stored in the little-endian byte order.

Uniform use of offset tables for all fields lets us take advantage of variable-length principle for integer fields.

...