Cassandra 2.1 introduces support for User-Defined Types (UDT) and tuple types.

User-defined types are declared at the keyspace level. A user-defined type simplifies handling a group of related properties. We can define a group of related properties as a type and access them separately or as a single entity. We can map our UDTs to application entities. Another new type for CQL introduced by Cassandra 2.1 is the tuple type. A tuple is a fixed-length set of typed positional fields without labels.

We can use user-defined and tuple types in tables. However, to support future capabilities, a column definition of a user-defined or tuple type requires the frozen keyword. Cassandra serializes a frozen value having multiple components into a single value. This means we cannot update parts of a UDT value. The entire value must be overwritten. Cassandra treats the value of a frozen UDT like a BLOB.

We create a UDT called contact in the packt keyspace and use it to define contactfield in table04. Moreover, we have another column, tuplefield, to store a tuple in a row. Pay attention to the syntax of the INSERT statement for UDT and tuple. For UDT, we may use a dotted notation to retrieve a component of the UDT column, such as contactfield.facebook in our following example. As shown in cassandra-cli, contactfield is stored as a single value, 00000001620000000163000000076440642e636f6d.

The value concatenates each UDT component in sequence with the format, a length of 4 bytes indicating the length of the component value and the component value itself. So, for contactfield.facebook, 0x00000001 is the length and 0x62 is the byte value of 'a'. Cassandra applies the same treatment to a tuple:

Experiment of user-defined and tuple types