Errata

As this is on Safari, I can't list the page number or location on the page.

In chapter 4, "The Cassandra Query Language", section "Secondary Indexes", there is the following statement:

"Note that for maps in particular, we have the option of indexing either the keys, via the syntax KEYS(addresses), or the values, which is the default. You may not create indexes on both the keys and values of a map."

This may have been true for the version used when writing this book, but it's not the case for the most recent version of Cassandra, and it's not clear exactly how far back this was not the case.

I have not personally verified this, but I cite the following from the #cassandra IRC channel:
------------------
davidmichaelkarr> David M. Karr Question about indexes. I found the following statement in "C:TDG": "Note that for maps in particular, we have the option of indexing either the keys, via the syntax KEYS(addresses), or the values, which is the default. You may not create indexes on both the keys and values of a map."
11:51:05 → nosukker joined (268c303a@gateway/web/cgi-irc/kiwiirc.com/ip.38.140.48.58)
11:51:41
<davidmichaelkarr> David M. Karr Is that saying you can't create a single index covering both the keys and the values, or is it saying that a particular map column cannot have both its keys and values indexed?
11:52:44
<thobbs> Tyler Hobbs davidmichaelkarr: I think it's saying both, but not all of that is necessarily true in recent C* versions
11:52:57 first, you can create an index on key-value pairs
11:53:09 and second, iirc, in 3.0+ you can index both keys and values separately
11:53:27 that might have actually been added in some later 3.x, but I think it's true in 3.0
11:53:36
<davidmichaelkarr> David M. Karr thobbs: Ok, so it's just not accurate for recent versions then. Ok.
11:53:59
<thobbs> Tyler Hobbs right
------------------

Note from the Author or Editor:
The change to allow both keys and values to be indexed appears to have been added in the 2.2 release (compare https://docs.datastax.com/en/cql/3.3/cql/cql_using/useIndexColl.html with https://docs.datastax.com/en/cql/3.1/cql/ddl/ddlIndexColl.html)

Please change the text:

"Note that for maps in particular, we have the option of indexing either the keys, via the syntax KEYS(addresses), or the values, which is the default. You may not create indexes on both the keys and values of a map."

to

"Note that for maps in particular, we have the option of indexing either the keys, via the syntax KEYS(addresses), or the values (which is the default), or both (in Cassandra 2.2 or later)."

I don't even know if it makes sense to report this error here, but on Safari books, the "URL" button on each page is supposed to produce a URL that should return to the same page, assuming the user is logged into Safari. This works perfectly fine on all the Safari books I've read in the past. For some reason, the URLs that I get for pages in this book only return to the table of contents of the book.

I just tested this again for two other books, and it still works fine. The URLs produced for this book just return to the TOC.

Note from the Author or Editor:
Confirmed that the links from individual pages in Safari Books Online do not work.

Confirmed Errata for previous section ("Calculating Partition Size") says that number of hotels should not be considered in partition size. Subsequent section (Calculating Size on Disk) also needs to be corrected. Number of hotels should have no effect on partition size limit nor partition size calculation. Data for given hotel would be stored on different partition.

Note from the Author or Editor:
Reader is correct, since there is a partition for each hotel, number of hotels is not a factor, and this should flow through calculations in both sections.

Nr=100rooms/hotel×730days=73,000rows

and

Partition size = 16 bytes + 0 bytes + 0.51 MB + 0.58 MB = 1.1 MB

The instructions below doesn't really update the row.
The last name and the timestamp value remain unchanged.
Cassandra silently ignores UPDATE instruction and on SELECT displays old value.


cqlsh:my_keyspace> UPDATE user USING TIMESTAMP 1434373756626000
SET last_name = 'Boateng' WHERE first_name = 'Mary' ;
cqlsh:my_keyspace> SELECT first_name, last_name,
WRITETIME(last_name) FROM user WHERE first_name = 'Mary';


cqlsh> SHOW VERSION;
[cqlsh 5.0.1 | Cassandra 3.7 | CQL spec 3.4.2 | Native protocol v4]

Note from the Author or Editor:
The comment is correct, the issue is that using the timestamp provided in the book is by definition in the past compared to the time you are running the example. If you use the timestamp provided in the book, the update will be considered an earlier change than your write. Therefore the update is valid, and no error message is generated.

The text that reads as follows:

To do this, we’ll use the CQL UPDATE command for the first time, using the
optional USING TIMESTAMP option:

Should be modified to the following:

To do this, we’ll use the CQL UPDATE command for the first time. We'll use the
optional USING TIMESTAMP option to manually set a timestamp (note that the timestamp must be later than the one from our SELECT command, or the UPDATE will be ignored):

The tinyint Cassandra type is defined as

tinyint: An 8-bit signed integer (as in Java)

Since Java does not have a primitive type called tinyint, for consistency with the other type definitions it would be better to define it as

tinyint: An 8-bit signed integer (equivalent to a Java byte)

Note from the Author or Editor:
Good recommendation. Please change as recommended to:

tinyint: An 8-bit signed integer (equivalent to a Java byte)

Now that we have defined our address type, we’ll try to use it in our user table, but if
you’re using Cassandra 2.1 or earlier, you’ll run into a problem:
cqlsh:my_keyspace> ALTER TABLE user ADD
addresses map<text, address>;
InvalidRequest: code=2200 [Invalid query] message="Non-frozen
collections are not allowed inside collections: map<text,
address>"

I am facing this issue in version 3.7 version of Cassandra, when the book reads that the version must be <= 2.1
cqlsh:my_keyspace> SHOW VERSION;
[cqlsh 5.0.1 | Cassandra 3.7 | CQL spec 3.4.2 | Native protocol v4]

Note from the Author or Editor:
This problem does still exist in releases through 3.7, see https://issues.apache.org/jira/browse/CASSANDRA-7826.

The reference to release 2.1 should be omitted, and the text modified to say: "Now that we have defined our address type, we’ll try to use it in our user table, but we immediately run into a problem"

The "create" table is listed like so

```
CREATE TABLE my_keyspace.user (
first_name text PRIMARY KEY,
addresses map<text, frozen<address>>,
emails set<text>,
id uuid,
last_name text,
login_sessions map<timeuuid, int>,
phone_numbers list<text>,
title text
) WITH bloom_filter_fp_chance = 0.01
AND caching = '{"keys":"ALL", "rows_per_partition":"NONE"}'
AND comment = ''
AND compaction = {'min_threshold': '4', 'class':
'org.apache.cassandra.db.compaction.
SizeTieredCompactionStrategy', 'max_threshold': '32'}
AND compression = {'sstable_compression':
'org.apache.cassandra.io.compress.LZ4Compressor'}
AND dclocal_read_repair_chance = 0.1
AND default_time_to_live = 0
AND gc_grace_seconds = 864000
AND max_index_interval = 2048
AND memtable_flush_period_in_ms = 0
AND min_index_interval = 128
AND read_repair_chance = 0.0
AND speculative_retry = '99.0PERCENTILE';
```

However, this throws two errors.

- caching needs to be a map
- map keys need to be single quoted

The string that actually works is the following. Note the changes to "caching"

```
CREATE TABLE my_keyspace.user (
first_name text PRIMARY KEY,
addresses map<text, frozen<address>>,
emails set<text>,
id uuid,
last_name text,
login_sessions map<timeuuid, int>,
phone_numbers list<text>,
title text
) WITH bloom_filter_fp_chance = 0.01
AND caching = {'keys':'ALL', 'rows_per_partition':'NONE'}
AND comment = ''
AND compaction = {'min_threshold': '4', 'class':
'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', 'max_threshold': '32'}
AND compression = {'sstable_compression': 'org.apache.cassandra.io.compress.LZ4Compressor'}
AND dclocal_read_repair_chance = 0.1
AND default_time_to_live = 0
AND gc_grace_seconds = 864000
AND max_index_interval = 2048
AND memtable_flush_period_in_ms = 0
AND min_index_interval = 128
AND read_repair_chance = 0.0
AND speculative_retry = '99.0PERCENTILE';
```

Note from the Author or Editor:
Reader is correct. The line describing the caching settings should have single quotes rather than double quotes:

AND caching = {'keys':'ALL', 'rows_per_partition':'NONE'}

cqlsh:my_keyspace> SELECT * FROM user WHERE last_name = 'Nguyen';
InvalidRequest: code=2200 [Invalid query] message="No supported
secondary index found for the non primary key columns restrictions"

Book says that after attempting to fetch values by the last name, user will see error message as following: code=2200 [Invalid query] message="No supported
secondary index found for the non primary key columns restrictions"
In reality it slightly differs:


InvalidRequest: code=2200 [Invalid query] message="Cannot execute this query as it might involve data filtering and thus may have unpredictable performance. If you want to execute this query despite the performance unpredictability, use ALLOW FILTERING"

cqlsh:my_keyspace> SHOW VERSION;
[cqlsh 5.0.1 | Cassandra 3.7 | CQL spec 3.4.2 | Native protocol v4]

Note from the Author or Editor:
Since the book includes many output examples, it’s inevitable that many of the statement formats will undergo slight changes in future versions of Cassandra.

The preface of the book should note more explicitly that examples were run against Cassandra 3.0.

Specifically, the following section should be revised:

Cassandra Versions Used in This Book
This book was developed using the Cassandra 3.X series of releases, along with the DataStax Java Driver version 3.0.

This statement should be revised to:

This book was developed using Apache Cassandra 3.0 and the DataStax Java Driver version 3.0. The formatting and content of tool output, log files, configuration files, and error messages are as they appear in the 3.0 release, and may change in future releases.

Author received the following comment: "Do you think that calculation on the page 97, section, calculating the partition size is right? I believe, number of values is calculated for a partition rather than entire rows. In your calculation you are calculating for 5000 hotels, but each hotel is a partition (available_room_by_hotel_date). So I believe your assumption is wrong. Could you please clarify the calculation? I refer the datastax online video tutorial, it also says about rows per partition rather than either rows."

The reader is correct, the number of hotels should not be included when calculating the number of rows per partition for this table, because each hotel will have its own partition.

Therefore the text should read as follows:

So the number of values for this table is equal to the number of rows. We still need to determine a number of rows. To do this, we make some estimates based on the application we’re designing. Our table is storing a record for each room, in each of our hotels, for every night. Let’s assume that our system will be used to store two years of inventory at a time, and there are 5,000 hotels in our system, with an average of 100 rooms in each hotel.

This leads an estimated number of rows as follows:
Nr = 100 rooms/hotel X 730 days = 73,000 rows

This relatively small number of rows per partition is not going to get us in too much trouble, but if we start adding a lot of hotels or don’t manage the size of our inventory well using TTL, we could start having issues. We still might want to look at breaking up this large partition, which we’ll do shortly.

N_pk should be the number of partition key columns instead of the number of primary key columns. Otherwise, clustering keys are not considered in the calculation of partition sizes.

Note from the Author or Editor:
I spoke with Artem Chebotko who created these formulas originally and updated them to account for the storage format changes that came in Apache Cassandra 3.0 with the new storage engine implementation.

Technically the description of the formula is correct, since the number of values is described as the number of cells, which is a specific reference to the storage format. Clustering column values are stored in a row header rather than as cells. This is a change from the pre-3.0 storage format, in which the clustering column values were stored as cells.

While the description is technically correct, I see how it can be confusing and potentially not very useful to omit the clustering column values from a calculation of the number of values. To include those values as well, you would multiply the number of rows by the number of clustering columns.

The last part of the first sentence "The random partitioner ..." states this partitioner "... is Cassandra's default". This should be replaced by "was Cassandra's default in Cassandra 1.1 and earlier".

Note from the Author or Editor:
Agree with recommended change as described above.

It looks that we are attempting to create a trust store at node 1 and are adding to it a certificate generated by the node 1. Not sure, if that makes sense. Does node 1 need to establish secure connection with itself?

$ keytool -import -v -trustcacerts -alias node1 -file node1.cer
-keystore node1.truststore

I would change it to:
$ keytool -import -v -trustcacerts -alias node1 -file node1.cer
-keystore nodeX.truststore

where X, is the node, where we create a trust store for node 1 and import certificate produced by node 1 into newly created trust store.

Note from the Author or Editor:
This is a good clarification. Node 1 doesn't need to add its own public cert.

I would replace the sentence "Each command looks something like the following:" with the sentence "For example, to add the certificate for node 1 to the keystore for node two, we would use the command: "

And the command should be changed to:

$ keytool -import -v -trustcacerts -alias node1 -file node1.cer
-keystore node2.truststore