Author: eevans
Date: Sun Dec  4 16:23:05 2011
New Revision: 1210136

URL: http://svn.apache.org/viewvc?rev=1210136&view=rev
Log:
push CQL documentation somewhere public

Added:
    cassandra/site/src/content/doc/
    cassandra/site/src/content/doc/cql/
    cassandra/site/src/content/doc/cql/CQL.css
    cassandra/site/src/content/doc/cql/CQL.html

Added: cassandra/site/src/content/doc/cql/CQL.css
URL: 
http://svn.apache.org/viewvc/cassandra/site/src/content/doc/cql/CQL.css?rev=1210136&view=auto
==============================================================================
--- cassandra/site/src/content/doc/cql/CQL.css (added)
+++ cassandra/site/src/content/doc/cql/CQL.css Sun Dec  4 16:23:05 2011
@@ -0,0 +1,48 @@
+/*
+ * 
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements.  See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership.  The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License.  You may obtain a copy of the License at
+ * 
+ *   http://www.apache.org/licenses/LICENSE-2.0
+ * 
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied.  See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ * 
+ */
+
+/* Just a sample of some things that might be helpful in rendering CQL.html */
+
+pre.sample {
+  padding: 1ex;
+  border: 1px solid black;
+  background-color: #ffe0e0;
+}
+pre.syntax {
+  padding: 1ex;
+  border: 1px solid black;
+  background-color: #e0e0ff;
+}
+table {
+  width: 80%;
+  border-collapse: collapse;
+  border: 1px solid black;
+}
+td {
+  padding: 2px 1ex;
+  border: 1px solid black;
+}
+body {
+  background-color: white;
+}
+h2 {
+  margin-top: 3em;
+}

Added: cassandra/site/src/content/doc/cql/CQL.html
URL: 
http://svn.apache.org/viewvc/cassandra/site/src/content/doc/cql/CQL.html?rev=1210136&view=auto
==============================================================================
--- cassandra/site/src/content/doc/cql/CQL.html (added)
+++ cassandra/site/src/content/doc/cql/CQL.html Sun Dec  4 16:23:05 2011
@@ -0,0 +1,247 @@
+<?xml version='1.0' encoding='utf-8' ?><!DOCTYPE html PUBLIC "-//W3C//DTD 
XHTML 1.0 Transitional//EN" 
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";><html 
xmlns="http://www.w3.org/1999/xhtml";><head><meta http-equiv="Content-Type" 
content="text/html; charset=utf-8"/><title>CQL</title></head><body><p><!-- This 
is only a suggestion, to demonstrate that the pre.syntax and pre.sample classes 
should probably be rendered differently. Render as you like. --><link 
rel="StyleSheet" href="CQL.css" type="text/css" media="screen"></p><h1 
id="CassandraQueryLanguageCQLv2.0">Cassandra Query Language (CQL) v2.0</h1><h2 
id="TableofContents">Table of Contents</h2><ol style="list-style: none;"><li><a 
href="CQL.html#CassandraQueryLanguageCQLv2.0">Cassandra Query Language (CQL) 
v2.0</a><ol style="list-style: none;"><li><a 
href="CQL.html#TableofContents">Table of Contents</a></li><li><a 
href="CQL.html#Syntaxconventions">Syntax conventions</a></li><li><a 
href="CQL.html#Overallsyntax">Ove
 rall syntax</a></li><li><a href="CQL.html#storageTypes">Data Storage 
Types</a><ol style="list-style: none;"><li><a 
href="CQL.html#usingdates">Working with dates</a></li></ol></li><li><a 
href="CQL.html#USE">USE</a></li><li><a href="CQL.html#SELECT">SELECT</a><ol 
style="list-style: none;"><li><a href="CQL.html#SpecifyingColumns">Specifying 
Columns</a></li><li><a href="CQL.html#ColumnFamily">Column 
Family</a></li><li><a href="CQL.html#ConsistencyLevel">Consistency 
Level</a></li><li><a href="CQL.html#Filteringrows">Filtering 
rows</a></li><li><a href="CQL.html#Limits">Limits</a></li></ol></li><li><a 
href="CQL.html#INSERT">INSERT</a></li><li><a 
href="CQL.html#update">UPDATE</a><ol style="list-style: none;"><li><a 
href="CQL.html#ColumnFamily2">Column Family</a></li><li><a 
href="CQL.html#ConsistencyLevel2">Consistency Level</a></li><li><a 
href="CQL.html#Timestamp">Timestamp</a></li><li><a 
href="CQL.html#TTL">TTL</a></li><li><a 
href="CQL.html#SpecifyingColumnsandRow">Specifying Colum
 ns and Row</a></li><li><a href="CQL.html#UpdatingCounterColumns">Updating 
Counter Columns</a></li></ol></li><li><a href="CQL.html#DELETE">DELETE</a><ol 
style="list-style: none;"><li><a href="CQL.html#SpecifyingColumns2">Specifying 
Columns</a></li><li><a href="CQL.html#ColumnFamily3">Column 
Family</a></li><li><a href="CQL.html#ConsistencyLevel3">Consistency 
Level</a></li><li><a href="CQL.html#deleterows">Specifying 
Rows</a></li></ol></li><li><a href="CQL.html#TRUNCATE">TRUNCATE</a></li><li><a 
href="CQL.html#BATCH">BATCH</a></li><li><a 
href="CQL.html#CREATEKEYSPACE">CREATE KEYSPACE</a></li><li><a 
href="CQL.html#CREATECOLUMNFAMILY">CREATE COLUMNFAMILY</a><ol 
style="list-style: none;"><li><a href="CQL.html#keytypes">Specifying Key 
Type</a></li><li><a href="CQL.html#SpecifyingColumnTypesoptional">Specifying 
Column Types (optional)</a></li><li><a 
href="CQL.html#ColumnFamilyOptionsoptional">Column Family Options 
(optional)</a></li></ol></li><li><a href="CQL.html#CREATEINDEX">CREATE
  INDEX</a></li><li><a href="CQL.html#DROPKEYSPACE">DROP 
KEYSPACE</a></li><li><a href="CQL.html#DROPCOLUMNFAMILY">DROP 
COLUMNFAMILY</a></li><li><a href="CQL.html#DROPINDEX">DROP INDEX</a></li><li><a 
href="CQL.html#ALTERCOLUMNFAMILY">ALTER COLUMNFAMILY</a><ol style="list-style: 
none;"><li><a href="CQL.html#Changingthetypeofatypedcolumn">Changing the type 
of a typed column</a></li><li><a href="CQL.html#Addingatypedcolumn">Adding a 
typed column</a></li><li><a href="CQL.html#Droppingatypedcolumn">Dropping a 
typed column</a></li></ol></li><li><a href="CQL.html#CommonIdioms">Common 
Idioms</a><ol style="list-style: none;"><li><a 
href="CQL.html#consistency">Specifying 
Consistency</a></li></ol></li></ol></li><li><a 
href="CQL.html#Versioning">Versioning</a></li><li><a 
href="CQL.html#Changes">Changes</a></li></ol><h2 id="Syntaxconventions">Syntax 
conventions</h2><p>To aid in specifying the CQL syntax, we will use the 
following conventions in this document:</p><ul><li>Language rules will
  be given in a <acronym title="Backus-Naur Form">BNF</acronym>-like notation, 
looking like this:</li></ul><pre class="syntax"><pre>&lt;Start> ::= 
&lt;CQL_Statement>*
+          ;
+</pre></pre><ul><li>Nonterminal symbols in syntax rules will have 
<code>&lt;angle brackets></code>.</li><li>Terminal symbols will be shown in 
<code>"single quotes"</code>.</li><li>As an additional shortcut notation to 
BNF, optional symbols (that can occur zero or one times) will be followed by a 
<code>?</code> marker. Optional symbols that can occur zero or any number of 
times will be followed by a <code>*</code> marker. Multiple symbols may be 
grouped together in <code>(parentheses)</code> to signify that they are all 
optional or repeatable together.</li><li>In a few cases where meaning is more 
easily conveyed through prose, we explain a symbol and its expansion without 
BNF.</li><li>Sample code will also be shown in a code block:</li></ul><pre 
class="sample"><pre>SELECT sample_usage FROM cql;
+</pre></pre><ul><li>References to keywords or pieces of CQL code in running 
text will be shown in a <code>fixed-width font</code>.</li></ul><h2 
id="Overallsyntax">Overall syntax</h2><p>CQL consists of statements. As in SQL, 
some statements directly make changes to data, some look up data, and some 
change the way data is stored.</p><p>All statements end with a 
semicolon.</p><pre class="syntax"><pre>&lt;CQL_Statement> ::= 
&lt;statementBody> ";"
+                  ;
+&lt;statementBody> ::= &lt;useStatement>
+                  | &lt;selectStatement>
+                  | &lt;dataChangeStatement>
+                  | &lt;schemaChangeStatement>
+                  ;
+&lt;dataChangeStatement> ::= &lt;insertStatement>
+                        | &lt;updateStatement>
+                        | &lt;batchStatement>
+                        | &lt;deleteStatement>
+                        | &lt;truncateStatement>
+                        ;
+&lt;schemaChangeStatement> ::= &lt;createKeyspaceStatement>
+                          | &lt;createColumnFamilyStatement>
+                          | &lt;createIndexStatement>
+                          | &lt;dropKeyspaceStatement>
+                          | &lt;dropColumnFamilyStatement>
+                          | &lt;dropIndexStatement>
+                          | &lt;alterTableStatement>
+                          ;
+</pre></pre><p>String literals and identifiers (including keyspace and column 
family names) are case-sensitive, but CQL keywords are not. We show CQL 
keywords in this document in <code>UPPERCASE</code> merely as a convention to 
aid readability.</p><p>Literal values can be expressed in several ways in 
CQL.</p><pre class="syntax"><pre>&lt;term> ::= "KEY"
+         | &lt;identifier>
+         | &lt;stringLiteral>
+         | &lt;integer>
+         | &lt;float>
+         | &lt;uuid>
+         ;
+</pre></pre><ul><li>An <code>&lt;identifier></code> is a letter followed by 
any sequence of letters, digits, or the underscore (<code>_</code>).</li><li>A 
<code>&lt;stringLiteral></code> is encased in <code>'single quotes'</code>. A 
single quote itself can be represented in a string literal by doubling it, as 
in SQL: <code>'Single quote -> '' &lt;-'</code>.</li><li>An 
<code>&lt;integer></code> consists of an optional minus sign (<code>-</code>) 
followed by one or more digits (<code>0-9</code>).</li><li>A 
<code>&lt;uuid></code> can be expressed in the canonical UUID form: 32 hex 
digits (<code>0-9</code> or <code>a-f</code>, case insensitive), separated by 
dashes (<code>-</code>) after the 8th, 12th, 16th, and 20th digits. Example: 
<code>01234567-0123-0123-0123-0123456789ab</code></li><li>A 
<code>&lt;float></code> is a series of one or more decimal digits, followed by 
a period (<code>.</code>), and one or more decimal digits following. Note that 
there is no provision for &#822
 0;e&#8221; notation, no optional <code>+</code> sign, and the forms 
<code>.42</code> and <code>42.</code> are not accepted. Use <code>0.42</code> 
and <code>42.0</code>.</li><li>Whitespace is not significant except to separate 
terms, and inside string literals.</li></ul><p>Comments in CQL can begin with a 
double dash (<code>--</code>) or a double slash (<code>//</code>) and extend to 
the end of the line. Multiline comments are enclosed in <code>/* ... 
*/</code>.</p><h2 id="storageTypes">Data Storage 
Types</h2><p><i>Syntax:</i></p><pre class="syntax"><pre>&lt;storageType> ::= 
"ascii"
+                | "bigint"
+                | "blob"
+                | "boolean"
+                | "counter"
+                | "decimal"
+                | "double"
+                | "float"
+                | "int"
+                | "text"
+                | "timestamp"
+                | "uuid"
+                | "varchar"
+                | "varint"
+                ;
+</pre></pre><p>The following table gives additional information on the 
available data 
types.</p><table><tr><th>type</th><th>description</th></tr><tr><td>ascii</td><td>ASCII
 character string</td></tr><tr><td>bigint</td><td>64-bit signed 
long</td></tr><tr><td>blob</td><td>Arbitrary bytes (no 
validation)</td></tr><tr><td>boolean</td><td>true or 
false</td></tr><tr><td>counter</td><td>Counter column (64-bit 
long)</td></tr><tr><td>decimal</td><td>Variable-precision 
decimal</td></tr><tr><td>double</td><td>64-bit IEEE-754 floating 
point</td></tr><tr><td>float</td><td>32-bit IEEE-754 floating 
point</td></tr><tr><td>int</td><td>32-bit signed 
int</td></tr><tr><td>text</td><td>UTF8 encoded 
string</td></tr><tr><td>timestamp</td><td>A timestamp. See <a 
href="#usingdates">Working with dates</a> below for more 
information.</td></tr><tr><td>uuid</td><td>Type 1 or type 4 
UUID</td></tr><tr><td>varchar</td><td>UTF8 encoded 
string</td></tr><tr><td>varint</td><td>Arbitrary-precision integer</td><
 /tr></table><p><em>Note: In addition to the recognized types listed above, it 
is also possible to supply a string containing the name of a class (a sub-class 
of <code>AbstractType</code> loadable by Cassandra). The class name should 
either be fully qualified, or relative to the 
<code>org.apache.cassandra.db.marshal</code> package.</em></p><h3 
id="usingdates">Working with dates</h3><p>Values serialized with the 
<code>timestamp</code> type are encoded as 64-bit signed integers representing 
a number of milliseconds since the standard base time known as &#8220;the 
epoch&#8221;: January 1 1970 at 00:00:00 GMT.</p><p>Timestamp types can be 
input in CQL as simple long integers, giving the number of milliseconds since 
the epoch, as defined above.</p><p>Timestamp types can also be input as string 
literals in any of the following ISO 8601 formats, each representing the time 
and date Jan 2, 2003, at 04:05:00 AM, GMT.:</p><ul><li><code>2011-02-03 
04:05+0000</code></li><li><code>2011-02-
 03 
04:05:00+0000</code></li><li><code>2011-02-03T04:05+0000</code></li><li><code>2011-02-03T04:05:00+0000</code></li></ul><p>The
 <code>+0000</code> above is an RFC 822 4-digit time zone specification; 
<code>+0000</code> refers to GMT. US Pacific Standard Time is 
<code>-0800</code>. The time zone may be omitted if desired&#8212; the date 
will be interpreted as being in the time zone under which the coordinating 
Cassandra node is configured.</p><ul><li><code>2011-02-03 
04:05</code></li><li><code>2011-02-03 
04:05:00</code></li><li><code>2011-02-03T04:05</code></li><li><code>2011-02-03T04:05:00</code></li></ul><p>There
 are clear difficulties inherent in relying on the time zone configuration 
being as expected, though, so it is recommended that the time zone always be 
specified for timestamps when feasible.</p><p>The time of day may also be 
omitted, if the date is the only piece that 
matters:</p><ul><li><code>2011-02-03</code></li><li><code>2011-02-03+0000</code></li></ul><p>In
 t
 hat case, the time of day will default to 00:00:00, in the specified or 
default time zone.</p><h2 id="USE">USE</h2><p><i>Syntax:</i></p><pre 
class="syntax"><pre>&lt;useStatement> ::= "USE" &lt;term>
+                 ;
+</pre></pre><p><i>Sample:</i></p><pre class="sample"><pre>USE myApp;
+</pre></pre><p>A <code>USE</code> statement consists of the <code>USE</code> 
keyword, followed by a valid keyspace name.  Its purpose is to assign the 
per-connection, current working keyspace.  All subsequent keyspace-specific 
actions will be performed in the context of the keyspace selected, unless 
otherwise specified, until another USE statement is issued or the connection 
terminates.</p><h2 id="SELECT">SELECT</h2><p><i>Syntax:</i></p><pre 
class="syntax"><pre>&lt;selectStatement> ::= "SELECT" &lt;whatToSelect>
+                        "FROM" ( &lt;name> "." )? &lt;name>
+                               ( "USING" "CONSISTENCY" &lt;consistencylevel> )?
+                               ( "WHERE" &lt;selectWhereClause> )?
+                               ( "LIMIT" &lt;integer> )?
+                    ;
+&lt;whatToSelect> ::= &lt;term> ( "," &lt;term> )*
+                 | ("FIRST" &lt;integer> )? "REVERSED"? &lt;columnRange>
+                 | "COUNT" "(" &lt;countTarget> ")"
+                 ;
+&lt;columnRange> ::= &lt;term> ".." &lt;term>
+                | "*"
+                ;
+&lt;countTarget> ::= "*"
+                | "1"
+                ;
+&lt;name> ::= &lt;identifier>
+         | &lt;stringLiteral>
+         | &lt;integer>
+         ;
+&lt;selectWhereClause> ::= &lt;relation> ( "AND" &lt;relation> )*
+                      | &lt;term> "IN" "(" &lt;term> ( "," &lt;term> )* ")"
+                      ;
+&lt;relation> ::= &lt;term> &lt;relationOperator> &lt;term>
+             ;
+&lt;relationOperator> ::= "=" | "&lt;" | ">" | "&lt;=" | ">="
+                     ;
+</pre></pre><p><i>Sample:</i></p><pre class="sample"><pre>SELECT Name, 
Occupation FROM People WHERE key IN (199, 200, 207);
+SELECT FIRST 3 REVERSED 'time199'..'time100' FROM Events;
+SELECT COUNT(*) FROM system.Migrations;
+</pre></pre><p>A <code>SELECT</code> is used to read one or more records from 
a Cassandra column family. It returns a result-set of rows, where each row 
consists of a key and a collection of columns corresponding to the 
query.</p><h3 id="SpecifyingColumns">Specifying Columns</h3><pre 
class="sample"><pre>SELECT col1, col2 FROM ...
+SELECT range_lo..range_hi FROM ...
+SELECT * FROM ...
+SELECT FIRST 4 REVERSED range_hi..range_lo FROM ...
+</pre></pre><p>The <code>SELECT</code> expression determines which columns 
will appear in the results and can take a few different forms, as shown above. 
The simplest is a comma-separated list of column names. Note that column names 
in Cassandra can be specified with string literals or integers, in addition to 
identifiers.</p><p>It is also possible to specify a range of column names. The 
range notation consists of start and end column names, separated by two periods 
(<code>..</code>). The set of columns returned for a range is start and end 
inclusive. A single star (<code>*</code>) may be used as a range to request 
&#8220;all columns&#8221;.</p><p>When using a range, it is sometimes useful to 
limit the number of columns that can be returned as part of each row (since 
Cassandra is schemaless, it is not necessarily possible to determine ahead of 
time how many columns will be in the result set). To accomplish this, use the 
<code>FIRST</code> clause with an integer to specify an
  upper limit on the number of columns returned per row. The default limit is 
10,000 columns.</p><p>The <code>REVERSED</code> option causes the sort order of 
the columns returned to be reversed. This affects the <code>FIRST</code> 
clause; when limiting the columns returned, the columns at the end of the range 
will be selected instead of the ones at the beginning of the range.</p><p>A 
<code>SELECT</code> expression may also be <code>COUNT(*)</code>. In this case, 
the result will be only one value: the number of rows which matched the 
query.</p><p>It is worth noting that unlike the projection in a SQL SELECT, 
there is no guarantee that the results will contain all of the columns 
specified, because Cassandra is schemaless.</p><h3 id="ColumnFamily">Column 
Family</h3><pre class="sample"><pre>SELECT ... FROM MyApp.LocationSnapshots ...;
+SELECT ... FROM EventTimeline ...;
+</pre></pre><p>The <code>FROM</code> clause is used to specify the Cassandra 
column family applicable to a <code>SELECT</code> query. Unlike other 
operations on column families, the keyspace in which the column family exists 
may also be specified by giving its name before the column family name, and 
separating them by a dot (<code>.</code>). If the keyspace is not specified, 
the current keyspace will be used, as per normal.</p><h3 
id="ConsistencyLevel">Consistency Level</h3><pre class="sample"><pre>SELECT ... 
USING CONSISTENCY QUORUM;
+</pre></pre><p>Following the column family clause is an optional <a 
href="#consistency">consistency level specification</a>.</p><h3 
id="Filteringrows">Filtering rows</h3><pre class="sample"><pre>SELECT ... WHERE 
KEY = 11194251 AND startdate = '2011-10-08-0500';
+SELECT ... WHERE KEY >= 'AM' and KEY =&lt; 'AZ' AND module = 17;
+SELECT ... WHERE keyalias IN ('key1', 'key2', 'key3', ...);
+</pre></pre><p>The <code>WHERE</code> clause provides for filtering the rows 
that appear in results.  The clause can filter on a key name, or range of keys, 
and in the case of indexed columns, on column values.  Key filters are 
specified using the <code>KEY</code> keyword or key alias name, followed by a 
relational operator (one of <code>=</code>, <code>></code>, <code>>=</code>, 
<code>&lt;</code>, and <code>&lt;=</code>), and then a term value.  When terms 
appear on both sides of a relational operator it is assumed the filter applies 
to an indexed column. With column index filters, the term on the left of the 
operator must be the name of the indexed column, and the term on the right is 
the value to filter <i>on</i>.</p><p><i>Note: The greater-than and less-than 
operators (<code>></code> and <code>&lt;</code>) result in key ranges that are 
inclusive of the terms. There is no supported notion of &#8220;strictly&#8221; 
greater-than or less-than; these operators are merely supp
 orted as aliases to <code>>=</code> and <code>&lt;=</code>.</i></p><h3 
id="Limits">Limits</h3><pre class="sample"><pre>SELECT ... WHERE favoriteArtist 
= 'The Mighty Mighty Bosstones' LIMIT 90000;
+</pre></pre><p>The <code>LIMIT</code> option to a <code>SELECT</code> 
expression limits the number of rows returned by a query. <code>LIMIT</code> 
defaults to 10,000 when left unset.</p><h2 
id="INSERT">INSERT</h2><p><i>Syntax:</i></p><pre 
class="syntax"><pre>&lt;insertStatement> ::= "INSERT" "INTO" &lt;name>
+                               "(" &lt;term> "," &lt;term> ( "," &lt;term> )* 
")"
+                      "VALUES" "(" &lt;term> "," &lt;term> ( "," &lt;term> )* 
")"
+                      ( "USING" &lt;usingOption> ( "AND" &lt;usingOption> )* )?
+                    ;
+&lt;usingOption> ::= "CONSISTENCY" &lt;consistencylevel>
+                | "TIMESTAMP" &lt;integer>
+                | "TTL" &lt;integer>
+                ;
+</pre></pre><p><i>Sample:</i></p><pre class="sample"><pre>INSERT INTO 
NerdMovies (KEY, 11924)
+                VALUES ('Serenity', 'Nathan Fillion')
+      USING CONSISTENCY LOCAL_QUORUM AND TTL 86400;
+</pre></pre><p>An <code>INSERT</code> is used to write one or more columns to 
a record in a Cassandra column family. No results are returned.</p><p>The first 
column name in the <code>INSERT</code> list must be the name of the column 
family key. Also, there must be more than one column name specified (Cassandra 
rows are not considered to exist with only a key and no associated 
columns).</p><p>Unlike in SQL, the semantics of <code>INSERT</code> and 
<code>UPDATE</code> are identical. In either case a record is created if none 
existed before, and updated when it does.  For information on query modifiers 
and types, see the <a href="#update"><code>UPDATE</code></a> section 
below.</p><h2 id="update">UPDATE</h2><p><i>Syntax:</i></p><pre 
class="syntax"><pre>&lt;updateStatement> ::= "UPDATE" &lt;name>
+                        ( "USING" &lt;usingOption> ( "AND" &lt;usingOption> )* 
)?
+                        "SET" &lt;assignment> ( "," &lt;assignment> )*
+                        "WHERE" &lt;updateWhereClause>
+                    ;
+&lt;assignment> ::= &lt;term> "=" &lt;term>
+               | &lt;term> "=" &lt;term> "+" &lt;term>
+               | &lt;term> "=" &lt;term> "-" &lt;term>
+               ;
+&lt;updateWhereClause> ::= &lt;term> "=" &lt;term>
+                      | &lt;term> "IN" "(" &lt;term> ( "," &lt;term> )* ")"
+                      ;
+</pre></pre><p><i>Sample:</i></p><pre class="sample"><pre>UPDATE NerdMovies 
USING CONSISTENCY ALL AND TTL 400
+       SET 'A 1194' = 'The Empire Strikes Back',
+           'B 1194' = 'Han Solo'
+     WHERE KEY = B70DE1D0-9908-4AE3-BE34-5573E5B09F14;
+UPDATE UserActionCounts SET total = total + 2 WHERE keyalias = 523;
+</pre></pre><p>An <code>UPDATE</code> is used to write one or more columns to 
a record in a Cassandra column family. No results are returned. The row key can 
be specified using the <code>KEY</code> keyword or by a key alias set per 
column family.</p><h3 id="ColumnFamily2">Column Family</h3><p>Statements begin 
with the <code>UPDATE</code> keyword followed by a Cassandra column family 
name.</p><h3 id="ConsistencyLevel2">Consistency Level</h3><pre 
class="sample"><pre>UPDATE Foo USING CONSISTENCY EACH_QUORUM ...
+</pre></pre><p>Following the column family identifier is an optional 
<code>USING</code> clause, which can specify the <a 
href="#consistency">consistency level</a> for the update, or the timestamp 
and/or the TTL for the new columns.</p><h3 id="Timestamp">Timestamp</h3><pre 
class="sample"><pre>UPDATE Foo USING TIMESTAMP=1318452291034 ...
+</pre></pre><p><code>UPDATE</code> supports setting client-supplied optional 
timestamp for modification.</p><h3 id="TTL">TTL</h3><pre 
class="sample"><pre>UPDATE Foo USING TTL=6800 ...
+</pre></pre><p><code>UPDATE</code> supports setting a time to live (TTL), in 
seconds, for each of the added columns.</p><h3 
id="SpecifyingColumnsandRow">Specifying Columns and Row</h3><pre 
class="sample"><pre>UPDATE ... SET col1 = val1, col2 = val2 WHERE KEY = key1;
+UPDATE ... SET col3 = val3 WHERE KEY IN (key1, key2, key3);
+UPDATE ... SET col4 = 22 WHERE keyalias = key4;
+</pre></pre><p>Rows are created or updated by supplying column names and 
values, after the <code>SET</code> keyword, in term assignment format. Multiple 
columns can be set by separating the name/value pairs using commas.  Each 
update statement requires a precise set of row keys to be specified using a 
<code>WHERE</code> clause and the <code>KEY</code> keyword or key alias.</p><h3 
id="UpdatingCounterColumns">Updating Counter Columns</h3><pre 
class="sample"><pre>UPDATE ... SET name1 = name1 + &lt;value> ...;
+UPDATE ... SET name1 = name1 - &lt;value> ...;
+</pre></pre><p>Counter columns can be incremented or decremented by an 
arbitrary numeric value though the assignment of an expression that adds or 
substracts the value.</p><h2 id="DELETE">DELETE</h2><p><i>Syntax:</i></p><pre 
class="syntax"><pre>&lt;deleteStatement> ::= "DELETE" ( &lt;term> ( "," 
&lt;term> )* )?
+                        "FROM" &lt;name>
+                        ( "USING" &lt;deleteOption> ( "AND" &lt;deleteOption> 
)* )?
+                        "WHERE" &lt;updateWhereClause>
+                    ;
+&lt;deleteOption> ::= "CONSISTENCY" &lt;consistencylevel>
+                 | "TIMESTAMP" &lt;integer>
+                 ;
+</pre></pre><p><i>Sample:</i></p><pre class="sample"><pre>DELETE col1, col2, 
col3 FROM Planeteers USING CONSISTENCY ONE WHERE KEY = 'Captain';
+DELETE FROM MastersOfTheUniverse WHERE KEY IN ('Man-At-Arms', 'Teela');
+</pre></pre><p>A <code>DELETE</code> is used to perform the removal of one or 
more columns from one or more rows. The key can be given using the 
<code>KEY</code> keyword or by the key alias set per column family.</p><h3 
id="SpecifyingColumns2">Specifying Columns</h3><p>Following the 
<code>DELETE</code> keyword is an optional comma-delimited list of column name 
terms. When no column names are specified, the remove applies to the entire 
row(s) matched by the <a href="#deleterows">WHERE clause</a>.</p><h3 
id="ColumnFamily3">Column Family</h3><p>The column family name follows the list 
of column names and the keyword <code>FROM</code>.</p><h3 
id="ConsistencyLevel3">Consistency Level</h3><p>Following the column family 
identifier is an optional <a href="#consistency">consistency level 
specification</a>.</p><h3 id="deleterows">Specifying Rows</h3><pre 
class="sample"><pre>DELETE ... WHERE KEY = 'some_key_value';
+DELETE ... WHERE keyalias IN (key1, key2);
+</pre></pre><p>The <code>WHERE</code> clause is used to determine to which 
row(s) a <code>DELETE</code> applies. The first form allows the specification 
of a single keyname using the <code>KEY</code> keyword (or by key alias) and 
the <code>=</code> operator.  The second form allows a list of keyname terms to 
be specified using the <code>IN</code> notation and a parenthesized list of 
comma-delimited keyname terms.</p><h2 
id="TRUNCATE">TRUNCATE</h2><p><i>Syntax:</i></p><pre 
class="syntax"><pre>&lt;truncateStatement> ::= "TRUNCATE" &lt;name>
+                      ;
+</pre></pre><p><i>Sample:</i></p><pre class="sample"><pre>TRUNCATE 
super_important_data;
+</pre></pre><p><code>TRUNCATE</code> accepts a single argument for the column 
family name, and permanently removes all data from said column family.</p><h2 
id="BATCH">BATCH</h2><p><i>Syntax:</i></p><pre 
class="syntax"><pre>&lt;batchStatement> ::= "BEGIN" "BATCH"
+                        ( "USING" &lt;usingOption> ( "AND" &lt;usingOption> )* 
)?
+                        &lt;batchStatementMember> ( ";" 
&lt;batchStatementMember> )*
+                     "APPLY" "BATCH"
+                   ;
+&lt;batchStatementMember> ::= &lt;insertStatement>
+                         | &lt;updateStatement>
+                         | &lt;deleteStatement>
+                         ;
+</pre></pre><p><i>Sample:</i></p><pre class="sample"><pre>BEGIN BATCH USING 
CONSISTENCY QUORUM AND TTL 8640000
+  INSERT INTO users (KEY, password, name) VALUES ('user2', 'ch@ngem3b', 
'second user')
+  UPDATE users SET password = 'ps22dhds' WHERE KEY = 'user2'
+  INSERT INTO users (KEY, password) VALUES ('user3', 'ch@ngem3c')
+  DELETE name FROM users WHERE key = 'user2'
+  INSERT INTO users (KEY, password, name) VALUES ('user4', 'ch@ngem3c', 
'Andrew')
+APPLY BATCH;
+</pre></pre><p><code>BATCH</code> supports setting a client-supplied optional 
global timestamp which will be used for each of the operations included in the 
batch.</p><p>A single consistency level is used for the entire batch. It 
appears after the <code>BEGIN BATCH</code> statement, and uses the standard <a 
href="#consistency">consistency level specification</a>. Batched statements 
default to <code>CONSISTENCY.ONE</code> when left unspecified.</p><p>Only data 
modification statements (specifically, <code>UPDATE</code>, 
<code>INSERT</code>, and <code>DELETE</code>) are allowed in a 
<code>BATCH</code> statement. <code>BATCH</code> is <em>not</em> an analogue 
for SQL transactions.</p><p><em>NOTE: While there are no isolation guarantees, 
<code>UPDATE</code> queries are atomic within a given record.</em></p><h2 
id="CREATEKEYSPACE">CREATE KEYSPACE</h2><p><i>Syntax:</i></p><pre 
class="syntax"><pre>&lt;createKeyspaceStatement> ::= "CREATE" "KEYSPACE" 
&lt;name>
+                                 "WITH" &lt;optionName> "=" &lt;optionVal>
+                                 ( "AND" &lt;optionName> "=" &lt;optionVal> )*
+                            ;
+&lt;optionName> ::= &lt;identifier>
+               | &lt;optionName> ":" &lt;identifier>
+               | &lt;optionName> ":" &lt;integer>
+               ;
+&lt;optionVal> ::= &lt;stringLiteral>
+              | &lt;identifier>
+              | &lt;integer>
+              ;
+</pre></pre><p><i>Sample:</i></p><pre class="sample"><pre>CREATE KEYSPACE 
Excelsior WITH strategy_class = 'SimpleStrategy'
+    AND strategy_options:replication_factor = 1;
+CREATE KEYSPACE Excalibur WITH strategy_class = 'NetworkTopologyStrategy'
+    AND strategy_options:DC1 = 1 AND strategy_options:DC2 = 3;
+</pre></pre><p>The <code>CREATE KEYSPACE</code> statement creates a new 
top-level namespace (aka &#8220;keyspace&#8221;). Valid names are any string 
constructed of alphanumeric characters and underscores. Names which do not work 
as valid identifiers or integers should be quoted as string literals. 
Properties such as replication strategy and count are specified during creation 
using the following accepted keyword 
arguments:</p><table><tr><th>keyword</th><th>required</th><th>description</th></tr><tr><td>strategy_class</td><td>yes</td><td>The
 name of the replication strategy class which should be used for the new 
keyspace. Some often-used classes are <code>SimpleStrategy</code> and 
<code>NetworkTopologyStrategy</code>.</td></tr><tr><td>strategy_options</td><td>no</td><td>Most
 strategies require additional arguments which can be supplied by appending the 
option name to the <code>strategy_options</code> keyword, separated by a colon 
(<code>:</code>).  For example, a strategy opti
 on of &#8220;DC1&#8221; with a value of &#8220;1&#8221; would be specified as 
<code>strategy_options:DC1 = 1</code>; replication_factor for SimpleStrategy 
could be 
<code>strategy_options:replication_factor=3</code>.</td></tr></table><h2 
id="CREATECOLUMNFAMILY">CREATE COLUMNFAMILY</h2><p><i>Syntax:</i></p><pre 
class="syntax"><pre>&lt;createColumnFamilyStatement> ::= "CREATE" 
"COLUMNFAMILY" &lt;name>
+                                    "(" &lt;term> &lt;storageType> "PRIMARY" 
"KEY"
+                                        ( "," &lt;term> &lt;storageType> )* ")"
+                                   ( "WITH" &lt;identifier> "=" 
&lt;cfOptionVal>
+                                     ( "AND" &lt;identifier> "=" 
&lt;cfOptionVal> )* )?
+                                ;
+&lt;cfOptionVal> ::= &lt;storageType>
+                | &lt;identifier>
+                | &lt;stringLiteral>
+                | &lt;integer>
+                | &lt;float>
+                ;
+</pre></pre><p><i>Sample:</i></p><pre class="sample"><pre>CREATE COLUMNFAMILY 
Fish (KEY blob PRIMARY KEY);
+CREATE COLUMNFAMILY FastFoodEatings (user text PRIMARY KEY)
+    WITH comparator=timestamp AND default_validation=int;
+CREATE COLUMNFAMILY MonkeyTypes (
+    KEY uuid PRIMARY KEY,
+    species text,
+    alias text,
+    population varint
+) WITH comment='Important biological records'
+   AND read_repair_chance = 1.0;
+</pre></pre><p><code>CREATE COLUMNFAMILY</code> statements create new column 
family namespaces under the current keyspace. Valid column family names are 
strings of alphanumeric characters and underscores, which begin with a 
letter.</p><h3 id="keytypes">Specifying Key Type</h3><pre 
class="sample"><pre>CREATE ... (KEY ascii PRIMARY KEY, ... ) ...
+</pre></pre><p>When creating a new column family, you must specify the key 
type. The list of possible types is identical to column comparators/validators 
(see <a href="#storageTypes">Data Storage Types</a>), except it probably does 
not make sense to use <code>counter</code> for a key. It&#8217;s important to 
note that the key type you use must be compatible with the partitioner in use. 
For example, <code>OrderPreservingPartitioner</code> and 
<code>CollatingOrderPreservingPartitioner</code> both require UTF-8 keys. If 
you use an identifier for the primary key name, instead of the <code>KEY</code> 
keyword, a key alias will be set automatically.</p><h3 
id="SpecifyingColumnTypesoptional">Specifying Column Types (optional)</h3><pre 
class="sample"><pre>CREATE ... ( ... , name1 type1, name2 type2, ... ) ...
+</pre></pre><p>It is possible to assign columns a type during column family 
creation. Columns configured with a type are validated accordingly when a write 
occurs, and intelligent CQL drivers and interfaces will be able to decode the 
column values correctly when receiving them. Column types are specified as a 
parenthesized, comma-separated list of column term and type pairs. See <a 
href="#storageTypes">Data Storage Types</a> for the list of recognized 
types.</p><h3 id="ColumnFamilyOptionsoptional">Column Family Options 
(optional)</h3><pre class="sample"><pre>CREATE COLUMNFAMILY ... WITH keyword1 = 
arg1 AND keyword2 = arg2;
+</pre></pre><p>A number of optional keyword arguments can be supplied to 
control the configuration of a new column 
family.</p><table><tr><th>keyword</th><th>default</th><th>description</th></tr><tr><td>comparator</td><td>text</td><td>Determines
 the storage type of column names (which itself determines the sorting and 
validation of column names). Valid values are listed in the <a 
href="#storageTypes">Data Storage Types</a> table 
above.</td></tr><tr><td>comment</td><td>none</td><td>A free-form, 
human-readable 
comment.</td></tr><tr><td>row_cache_provider</td><td>SerializingCacheProvider 
if JNA is present, otherwise ConcurrentHashMapCacheProvider</td><td>A factory 
for the cache with which to back the row 
cache.</td></tr><tr><td>row_cache_size</td><td>0</td><td>Number of rows whose 
entire contents to cache in 
memory.</td></tr><tr><td>key_cache_size</td><td>200000</td><td>Number of keys 
per SSTable whose locations are kept in memory in &#8220;mostly LRU&#8221; 
order.</td></tr><tr>
 <td>read_repair_chance</td><td>1.0</td><td>The probability with which read 
repairs should be invoked on non-quorum 
reads.</td></tr><tr><td>gc_grace_seconds</td><td>864000</td><td>Time to wait 
before garbage collecting tombstones (deletion 
markers).</td></tr><tr><td>default_validation</td><td>text</td><td>Determines 
the default storage type of column values (which itself determines the 
validation for column values). This option does not affect the types of columns 
which were defined in a <code>CREATE COLUMNFAMILY</code> statement&#8212; only 
new columns. Valid values are listed in the <a href="#storageTypes">Data 
Storage Types</a> table 
above.</td></tr><tr><td>min_compaction_threshold</td><td>4</td><td>Minimum 
number of SSTables needed to start a minor 
compaction.</td></tr><tr><td>max_compaction_threshold</td><td>32</td><td>Maximum
 number of SSTables allowed before a minor compaction is 
forced.</td></tr><tr><td>row_cache_save_period_in_seconds</td><td>0</td><td>Number
 of seco
 nds between saving row 
caches.</td></tr><tr><td>key_cache_save_period_in_seconds</td><td>14400</td><td>Number
 of seconds between saving key 
caches.</td></tr><tr><td>replicate_on_write</td><td>false</td><td></td></tr></table><h2
 id="CREATEINDEX">CREATE INDEX</h2><p><i>Syntax:</i></p><pre 
class="syntax"><pre>&lt;createIndexStatement> ::= "CREATE" "INDEX" 
&lt;identifier>? "ON"
+                               &lt;name> "(" &lt;term> ")"
+                         ;
+</pre></pre><p><i>Sample:</i></p><pre class="sample"><pre>CREATE INDEX 
userIndex ON NerdMovies (user);
+CREATE INDEX ON Mutants (abilityId);
+</pre></pre><p>A <code>CREATE INDEX</code> statement is used to create a new, 
automatic secondary index on the given column family, for the named column. A 
name for the index itself can be specified before the <code>ON</code> keyword, 
if desired. A single column name must be specified inside the parentheses. It 
is not necessary for the column to exist on any current rows (Cassandra is 
schemaless), but the column must already have a type (specified during the 
<code>CREATE COLUMNFAMILY</code>, or added afterwards with <code>ALTER 
COLUMNFAMILY</code>.</p><h2 id="DROPKEYSPACE">DROP 
KEYSPACE</h2><p><i>Syntax:</i></p><pre 
class="syntax"><pre>&lt;dropKeyspaceStatement> ::= "DROP" "KEYSPACE" &lt;name>
+                          ;
+</pre></pre><p><i>Sample:</i></p><pre class="sample"><pre>DROP KEYSPACE 
MyTwitterClone;
+</pre></pre><p>A <code>DROP KEYSPACE</code> statement results in the 
immediate, irreversible removal of a keyspace, including all column families in 
it, and all data contained in those column families.</p><h2 
id="DROPCOLUMNFAMILY">DROP COLUMNFAMILY</h2><p><i>Syntax:</i></p><pre 
class="syntax"><pre>&lt;dropColumnFamilyStatement> ::= "DROP" "COLUMNFAMILY" 
&lt;name>
+                              ;
+</pre></pre><p><i>Sample:</i></p><pre class="sample"><pre>DROP COLUMNFAMILY 
worldSeriesAttendees;
+</pre></pre><p>A <code>DROP COLUMNFAMILY</code> statement results in the 
immediate, irreversible removal of a column family, including all data 
contained in it.</p><h2 id="DROPINDEX">DROP INDEX</h2><p><i>Syntax:</i></p><pre 
class="syntax"><pre>&lt;dropIndexStatement> ::= "DROP" "INDEX" &lt;name>
+                       ;
+</pre></pre><p><i>Sample:</i></p><pre class="sample"><pre>DROP INDEX 
cf_col_idx;
+</pre></pre><p>A <code>DROP INDEX</code> statement is used to drop an existing 
secondary index.</p><h2 id="ALTERCOLUMNFAMILY">ALTER 
COLUMNFAMILY</h2><p><i>Syntax:</i></p><pre 
class="syntax"><pre>&lt;alterTableStatement> ::= "ALTER" "COLUMNFAMILY" 
&lt;name> &lt;alterInstructions>
+                        ;
+&lt;alterInstructions> ::= "ALTER" &lt;name> "TYPE" &lt;storageType>
+                      | "ADD" &lt;name> &lt;storageType>
+                      | "DROP" &lt;name>
+                      ;
+</pre></pre><p>An <code>ALTER</code> statement is used to manipulate column 
family column metadata. It allows you to add new columns, drop existing 
columns, or change the data storage type of existing columns. No results are 
returned.</p><p>Specify the name of the column family to be changed after the 
<code>ALTER COLUMNFAMILY</code> keywords, and the name of the column to be 
changed, added, or dropped after the keyword corresponding to the type of 
change desired (<code>ALTER</code>, <code>ADD</code>, 
<code>DROP</code>).</p><h3 id="Changingthetypeofatypedcolumn">Changing the type 
of a typed column</h3><pre class="sample"><pre>ALTER COLUMNFAMILY addamsFamily 
ALTER lastKnownLocation TYPE uuid;
+</pre></pre><p><code>ALTER COLUMNFAMILY ... ALTER</code> changes the expected 
storage type for a column. The column must already have a type in the column 
family metadata. The column may or may not already exist in current rows&#8212; 
but be aware that no validation of existing data is done. The bytes stored in 
values for that column will remain unchanged, and if existing data is not 
deserializable according to the new type, this may cause your CQL driver or 
interface to report errors.</p><h3 id="Addingatypedcolumn">Adding a typed 
column</h3><pre class="sample"><pre>ALTER COLUMNFAMILY addamsFamily ADD 
gravesite varchar;
+</pre></pre><p>The <code>ALTER COLUMNFAMILY ... ADD</code> variant adds a 
typed column to a column family. The column must not already have a type in the 
column family metadata. The same warnings from the above <code>ALTER</code> 
section, about there being no validation of existing data, apply here as 
well.</p><h3 id="Droppingatypedcolumn">Dropping a typed column</h3><pre 
class="sample"><pre>ALTER COLUMNFAMILY addamsFamily DROP gender;
+</pre></pre><p>An <code>ALTER COLUMNFAMILY ... DROP</code> statement removes 
the type of a column from the column family metadata. Note that this does 
<em>not</em> remove the column from current rows; it just removes the metadata 
saying that the bytes stored under that column are expected to be 
deserializable according to a certain type.</p><h2 id="CommonIdioms">Common 
Idioms</h2><h3 id="consistency">Specifying Consistency</h3><pre 
class="syntax"><pre>&lt;consistency> ::= "ANY"
+                | "ONE"
+                | "QUORUM"
+                | "ALL"
+                | "LOCAL_QUORUM"
+                | "EACH_QUORUM"
+                ;
+</pre></pre><pre class="sample"><pre>... USING CONSISTENCY LOCAL_QUORUM ...
+</pre></pre><p>Consistency level specifications are made up the keywords 
<code>USING CONSISTENCY</code>, followed by a consistency level identifier. 
Valid consistency level identifiers are as listed above. When not specified, 
<code>USING CONSISTENCY ONE</code> is the default.</p><p>Consult your Cassandra 
documentation for information about how consistency levels work.</p><h1 
id="Versioning">Versioning</h1><p>Versioning of the CQL language adheres to the 
<a href="http://semver.org";>Semantic Versioning</a> guidelines.  Versions take 
the form X.Y.Z where X, Y, and Z are integer values representing major, minor, 
and patch level respectively.  There is no correlation between Cassandra 
release versions and the CQL language 
version.</p><table><tr><th>version</th><th>description</th></tr><tr><td>Major</td><td>The
 major version <em>must</em> be bumped when backward incompatible changes are 
introduced.  This should rarely (if ever) 
occur.</td></tr><tr><td>Minor</td><td>Minor version i
 ncrements occur when new, but backward compatible, functionality is 
introduced.</td></tr><tr><td>Patch</td><td>The patch version is incremented 
when bugs are fixed.</td></tr></table><h1 id="Changes">Changes</h1><pre>Wed, 12 
Oct 2011 16:53:00 -0500 - paul cannon
+ * Rework whole doc, adding syntax specifics and additional explanations
+
+Fri, 09 Sep 2011 11:43:00 -0500 - Jonathan Ellis
+ * add int data type
+
+</pre><pre>Wed, 07 Sep 2011 09:01:00 -0500 - Jonathan Ellis
+ * Updated version to 2.0; Documented row-based count()
+ * Updated list of supported data types
+</pre><pre>Wed, 10 Aug 2011 11:22:00 -0500 - Eric Evans
+ * Improved INSERT vs. UPDATE wording.
+ * Documented counter column incr/descr.
+</pre><pre>Sat, 01 Jun 2011 15:58:00 -0600 - Pavel Yaskevich
+ * Updated to support ALTER (CASSANDRA-1709)
+</pre><pre>Tue, 22 Mar 2011 18:10:28 -0700 - Eric Evans 
&lt;eev...@rackspace.com>
+ * Initial version, 1.0.0
+</pre></body></html>
\ No newline at end of file


Reply via email to