Table and column options

The table creation statement given in the previous section is very simple: little more than a list of column names and their respective types. In contrast, an SQL CREATE TABLE statement will often look quite complex, with multiple options set on each column, such as defaults, constraints, and nullability flags. What sorts of bells and whistles can we add to a CQL table?

At the table level, Cassandra does have quite a few configuration options known as table properties. These properties allow you to tune a wide range of under-the-hood aspects of the table, such as caching, compression, garbage collection, and read repair. Table properties do not, however, bear on the table's behavior from the application's standpoint. For this reason, we won't go into detail about them in this book.Columns, on the other hand, have very few knobs to turn. In fact, outside of the type, each column is pretty much the same. There are several column options you may be accustomed to from SQL databases that don't carry over to Cassandra, such as the following:

• Cassandra doesn't have a concept of null values; columns either have data, or they don't. Primary key columns are always required to have a value; non-key columns are always optional. You will see the word null appear in the cqlsh output, but that simply means there is no data in this column and should not be confused with the concept of null in a relational database.
• Cassandra doesn't support default values for columns. If a row is inserted without a value for a certain column, that column just doesn't have a value.
• Cassandra doesn't provide data validations such as length limits or other more complex column constraints. As long as a value is of the right type for the column you're putting it in, it's valid.

Fortunately, most modern applications do not need to rely on the sorts of aforementioned constraints; domain modeling libraries and object mappers typically allow you to easily apply these constraints at the application level.