Tuple and User-Defined Types

The driver supports Tuple and user-defined complex types which were introduced with Apache Cassandra 2.1. As long as there are no complex types nested in either the Tuple or user-defined types, the driver normalizes Tuple and user-defined types by flattening them into a relational version of the native Cassandra table. Take for example the following Cassandra table:

CREATE TABLE agents1 (
agentid int PRIMARY KEY,
email varchar,
contact tuple<varchar,varchar,varchar>);

The following agents1 table is a tabular representation of the native Cassandra table with data included.

Table 8. agents1 (native)
agentid (primary key)	email	contact
int	varchar	tuple<varchar, varchar, varchar>
272	barronr@email.com	tv newspaper blog
564	rothm@email.com	radio tv magazine

For the relational version of agents1, all fields are retained as separate columns, and columns with primitive types (agentid and email) correspond directly to columns in the native table. In turn, tuple fields are flattened into columns using a <tuplename>_<ordinal> naming pattern. The driver normalizes agents1 in the following manner.

Table 9. agents1 (relational)
agentid (primary key)	email	contact_1	contact_2	contact_3
int	varchar	varchar	varchar	varchar
272	barronr@email.com	tv	newspaper	blog
564	rothm@email.com	radio	tv	magazine

A SQL command would take the following form:

INSERT INTO agents1 (agentid,email,contact_1,contact_2,contact_3) VALUES (839,'gonzalesn@email.com','radio','tv','magazine')

The driver also flattens user-defined types when normalizing native Cassandra tables. In the following example, the native Cassandra agents2 table incorporates the user-defined address type.

CREATE TYPE address (
street varchar,
city varchar,
state varchar,
zip int);
CREATE TABLE agents2 (
agentid int PRIMARY KEY,
email varchar,
location frozen<address>);

The following agents2 table is a tabular representation of the native Cassandra table with data included.

Table 10. agents2 (native)
agentid (primary key)	email	location
int	varchar	address<street: varchar, city: varchar, state: varchar, zip: int>
095	barronr@email.com	street: 1551 Main Street city: Pittsburgh state: PA zip: 15237
237	rothm@email.com	street: 422 First Street city: Richmond state: VA zip: 23235

As with the previous example, all fields are retained as separate columns in the relational version of the table, and columns with primitive types (agentid and email) correspond directly to columns in the native table. Here a <columnname>_<fieldname> naming pattern is used to flatten the fields of the user-defined address type into columns. The driver normalizes agents2 in the following manner.

Table 11. agents2 (native)
agentid (primary key)	email	location_street	location_city	location_state	location_zip
int	varchar	varchar	varchar	varchar	int
095	barronr@email.com	1551 Main Street	Pittsburgh	PA	15237
237	rothm@email.com	422 First Street	Richmond	VA	23235

A SQL command would take the following form:

INSERT INTO agents2 (agentid,email,location_street,location_city,location_state,location_zip) VALUES (839,'gonzalesn@email.com','9 Fifth Street', 'Morrisville', 'NC', 27566)