pg亡灵大盗奖金翻倍了吗

書名： Learning Apache Cassandra
作者名： Mat Brown
本章字數： 560字
更新時間： 2021-07-23 20:34:48

Inserting data

For our status sharing application, the first thing we'll want any user to do is to create an account. We'll ask them to choose a username, enter their email, and pick a password; our business logic will be responsible for ensuring that the entries are valid and for encrypting the password appropriately. At that point, we'll be ready to insert the account information as a new row in the users table:

INSERT INTO "users"
("username", "email", "encrypted_password")
VALUES (
  'alice',
  'alice@gmail.com',
  0x8914977ed729792e403da53024c6069a9158b8c4
);

In the previous statement, which should be familiar to anyone who has used an SQL database, we provide the following information:

We want to add a row to the users table
We'll be adding data to three columns in that row: username, email, and encrypted_password
Finally, we provide the values to insert into those columns, in the same order that the column names were listed previously

Note

Does whitespace matter?

CQL is agnostic about whitespace. The query as written uses a lot of newlines for readability, but the query would be just as valid written on a single line.

Type the preceding CQL statement into your Cassandra shell (don't forget about the semicolon at the end!) Did it work? At first glance, it may be hard to tell.

Writing data does not yield feedback

If the INSERT statement worked, you should not see any response in the shell whatsoever; it should simply provide you with a new command prompt. This is not simply a quirk of the CQL shell, but a fundamental fact about writing data in Cassandra: writing data does not normally result in any information about the operation from the database, other than an error message if the write failed. Most client libraries will return a null value, or the equivalent in the language in question, when you perform a successful write query.

This may come as a surprise if you're used to working with an SQL database, which will typically give you detailed feedback when you write data, such as returning the primary key of the new row or simply telling you how many rows were affected by the operation.

We'll see some exceptions to this rule when we explore lightweight transactions in Chapter 7, Expanding Your Data Model.

Partial inserts

You are not, of course, required to provide values for all columns—other than primary key columns—when inserting a row. If, for instance, we decide to allow users to register without providing an email, we may issue this perfectly valid query:

INSERT INTO "users"
("username", "encrypted_password")
VALUES (
  'bob',
  0x10920941a69549d33aaee6116ed1f47e19b8e713
);

In the above query, we only insert values for the username and encrypted_password fields; the row will have no value in the email field.

Note

Do empty columns take up space?

Only columns with values take up storage space in Cassandra. This is in contrast to relational databases in which every row has space allocated for every column, whether or not that column has a value. So, there's little downside to defining columns in Cassandra that you expect to rarely populate; they'll only take up space where they have values.

For a full reference on the INSERT statement in CQL, consult the DataStax CQL documentation at http://www.datastax.com/documentation/cql/3.1/cql/cql_reference/insert_r.html. We haven't explored all of the possibilities for INSERT statements yet, but we'll cover many of them in future chapters.

官术网_书友最值得收藏!

Learning Apache Cassandra

Inserting data

Note

Writing data does not yield feedback

Partial inserts

Note