Database Reference
In-Depth Information
CREATE TABLE [ IF NOT EXISTS ] [keyspace_name.]table_name
( column_definition, column_definition, ...)
[WITH property [ AND property ... ]]
Column definition, in most of the common cases, will be as follows:
column_name column_type [STATIC | PRIMARY KEY]
Let's take a look at the following example:
CREATE TABLE mytab (id int PRIMARY KEY, name varchar,
article text, is_paying_user boolean, phone_numbers set
<varchar>);
You may define
PRIMARY KEY
separately, like we do in the case of the compound key:
CREATE TABLE team_match (city varchar, team_name varchar,
is_participating boolean, player_id set <int>, PRIMARY
KEY(city, team_name));
With Cassandra 2.1, you could create tables that have custom types, and on the same
working principle it lets you create tuples. There is a special way to declare a tuple or cus-
tom type. You use the
frozen
keyword for them. The pattern is as follows:
column_name frozen<tuple<type [, type, ...]>> [PRIMARY KEY]
column_name frozen<user_defined_type> [PRIMARY KEY]
So, what does
frozen
signify? Cassandra serializes the tuple or user defined type into
one cell. It may be noted that although the collections live in separate cells, if you have
nested collections, the inner collections are serialized into one cell. This means when you
update a user defined type or tuple, it pulls the whole thing, updates it, and inserts it again.
But Cassandra might allow individual updates in version 3.0 and above. So, the
frozen
keyword is just a safety feature to avoid conflicts when you migrate to the third version.
For now, you cannot create a column of user defined type, or tuple type without adding
in action:
cqlsh:demo_cql> CREATE TYPE address (line1 varchar, line2
varchar, city varchar, state varchar, postalcode int);
