cassandra keys

If your PType does not define a primary key, longevity generates a UUID and stores it in a column named id, which serves as the Cassandra table’s primary key. This column will be used for update and delete operations.

If you do define a primary key, longevity will use the property columns described in the previous section to build your Cassandra primary key. If you do not specify a partial partition, then all of the columns will become part of a Cassandra composite partition key. If you do specify a partial partition, then those columns that make up your partial partition will become the Cassandra partition key, and the remaining columns will make up the remainder of your primary key. Longevity will use these columns for updates and deletes.

In Cassandra, the partition key is always hashed. Any remaining columns in a partially partitioned primary key will be ranged, ascending. (While Cassandra supports these columns being ranged in descending order, we do not currently pass on that functionality to the longevity user.)

Please be aware that Cassandra will not reject create operations for objects that have the same primary key as an existing object. Rather, it will simply overwrite these rows.