ID | IEP-54 | ||||||||
Author | |||||||||
Sponsor | |||||||||
Created |
| ||||||||
Status |
|
...
The suggested list of supported built-in data types is listed in the table below:
Type | Size | Description |
---|---|---|
Bitmask(n) | ⌈n/8⌉ bytes | A fixed-length bitmask of n bits |
Byte | 1 byte | 1-byte signed integer |
Short | 2 bytes | 2-byte signed integer |
Integer | 4 bytes | 4-byte signed integer |
Long | 8 bytes | 8-byte signed integer |
Float | 4 bytes | 4-byte floating-point number |
Double | 8 bytes | 8-byte floating-point number |
Number([n]) | Variable | Variable-length number (optionally bound by n bytes in size) |
Decimal | Variable | Variable-length floating point number |
UUID | 16 bytes | UUID |
String | Variable | String encoded with a given Charset |
Date | 3 bytes | A timezone-free date encoded as day/month (1 byte), year (2 bytes) |
Time | 5 bytes | A timezone-free time encoded as hour (1 byte), minute (1 byte), second (1 byte), millisecond (2 bytes) |
Datetime | 8 bytes | A timezone-free datetime encoded as (date, time) |
Instant | 8 bytes | Number of milliseconds since Jan 1, 1970 00:00:00.000 (with no timezone) |
BLOB | Variable | Variable-size byte array |
Given a set of user-defined columns, this set is then rearranged so that fixed-sized columns go first. This sorted set of columns is used to form a tuple. Tuple layout is as follows:
Field | Size |
---|---|
Schema version | 1 byte |
Key columns hash | 4 bytes |
Key columns: | |
Key columns full size | 2 (3?) bytes |
Key columns varsize columns offsets table size | 2 bytes |
Key columns varsize columns offsets table | Variable (number of non-null varsize columns * 2(3?)) |
Key columns null map | ⌈number of columns / 8⌉ |
Key columns fixed size values | Variable |
Key columns variable size values | Variable |
Value columns: | |
Value columns full size | 2 (3?) bytes |
Value columns varsize columns offsets table size | 2 bytes |
Value columns varsize columns offsets table | Variable (number of non-null varsize columns * 2(3?)) |
Value columns null map | ⌈number of columns / 8⌉ |
Value columns fixed size values | Variable |
Value columns variable size values | Variable |
Unlike Ignite 2.x approach, where binary object schema ID is defined by a set of fields which are present in a binary object, for the schema-first approach we assign a monotonically growing identifier to each version of the cache schema. The ordering guarantees should be provided by the underlying metadata storage layer (for example, the current distributed metastorage implementation or a consensus-based metadata storage). The schema identifier should be stored together with the data tuples (but not necessarily with each tuple individually: we can store schema ID along with a page or larger chunks of data). The history of schema versions must be stored for a long enough period of time to allow upgrade all existing data stored in a given cache.
...
Given the set of fields in the target class, Ignite may optimize the amount of data sent over the network by skipping fields that would be ignored during deserialization.
Ignite will provide out-of-box mapping from standard platform types (Java, C#, C++) to built-in primitives. A user will be able to alter this mapping using some external mechanism (e.g. annotations to map long values to Number). Standard mapping is listed in the table below:
Built-in | Java | C# | C++ |
---|---|---|---|
Bitmask(n) | BitSet | ||
Byte | byte (Byte if nullable) | ||
Short | short (Short if nullable) | ||
Integer | int (Integer if nullable) | ||
Long | long (Long if nullable) | ||
Float | float (Float if nullable) | ||
Double | double (Double if nullable) | ||
Number([n]) | BigInteger | ||
Decimal | BigDecimal | ||
UUID | UUID | ||
String | String | ||
Date | LocalDate | ||
Time | LocalTime | ||
Datetime | LocalDateTime | ||
Instant | Date (Instant?) | ||
BLOB | byte[] |
...