Author: slebresne
Date: Mon Jul 16 17:22:05 2012
New Revision: 1362147
URL: http://svn.apache.org/viewvc?rev=1362147&view=rev
Log:
Minor update to CQL3 doc
Modified:
cassandra/site/publish/doc/cql3/CQL.html
Modified: cassandra/site/publish/doc/cql3/CQL.html
URL:
http://svn.apache.org/viewvc/cassandra/site/publish/doc/cql3/CQL.html?rev=1362147&r1=1362146&r2=1362147&view=diff
==============================================================================
--- cassandra/site/publish/doc/cql3/CQL.html (original)
+++ cassandra/site/publish/doc/cql3/CQL.html Mon Jul 16 17:22:05 2012
@@ -206,7 +206,7 @@ WHERE event_type = 'myEvent'
AND time <= 2012-01-01
SELECT COUNT(*) FROM users;
-</pre></pre><p><br/>The <code>SELECT</code> statements reads one or more
columns for one or more rows in a table. It returns a result-set of rows, where
each row contains the collection of columns corresponding to the query.</p><h4
id="selectSelection"><code><select-clause></code></h4><p>The
<code><select-clause></code> determines which columns needs to be queried
and returned in the result-set. It consists of either the comma-separated list
of column names to query, or the wildcard character (<code>*</code>) to select
all the columns defined for the table.</p><p>In addition to selecting columns,
the <code>WRITETIME</code> (resp. <code>TTL</code>) function allows to select
the timestamp of when the column was inserted (resp. the time to live (in
seconds) for the column (or null if the column has no expiration
set)).</p><p>The <code>COUNT</code> keyword can be used with parenthesis
enclosing <code>*</code>. If so, the query will return a single result: the
number of row
s matching the query. Note that <code>COUNT(1)</code> is supported as an
alias.</p><h4 id="selectWhere"><code><where-clause></code></h4><p>The
<code><where-clause></code> specifies which rows must be queried. It is
composed of relations on the columns that are part of the <code>PRIMARY
KEY</code> and/or have a <a href="#createIndexStmt">secondary index</a> defined
on them.</p><p>Not all relations are allowed in a query. For instance,
non-equal relations (where <code>IN</code> is considered as an equal relation)
on a partition key is only supported if the partitioner for the keyspace is an
ordered one. Moreover, for a given partition key, the clustering keys induce an
ordering of rows and relations on them is restricted to the relations that
allow to select a <strong>contiguous</strong> (for the ordering) set of rows.
For instance, given</p><p>When specifying relations, the <code>TOKEN</code>
function can be used on the <code>PARTITION KEY</code> column to query. In tha
t case, rows will be selected based on the token of their
<code>PARTITION_KEY</code> rather than on the value (note that the token of a
key depends on the partitioner in use).</p><pre class="sample"><pre>CREATE
TABLE posts (
+</pre></pre><p><br/>The <code>SELECT</code> statements reads one or more
columns for one or more rows in a table. It returns a result-set of rows, where
each row contains the collection of columns corresponding to the query.</p><h4
id="selectSelection"><code><select-clause></code></h4><p>The
<code><select-clause></code> determines which columns needs to be queried
and returned in the result-set. It consists of either the comma-separated list
of column names to query, or the wildcard character (<code>*</code>) to select
all the columns defined for the table.</p><p>In addition to selecting columns,
the <code>WRITETIME</code> (resp. <code>TTL</code>) function allows to select
the timestamp of when the column was inserted (resp. the time to live (in
seconds) for the column (or null if the column has no expiration
set)).</p><p>The <code>COUNT</code> keyword can be used with parenthesis
enclosing <code>*</code>. If so, the query will return a single result: the
number of row
s matching the query. Note that <code>COUNT(1)</code> is supported as an
alias.</p><h4 id="selectWhere"><code><where-clause></code></h4><p>The
<code><where-clause></code> specifies which rows must be queried. It is
composed of relations on the columns that are part of the <code>PRIMARY
KEY</code> and/or have a <a href="#createIndexStmt">secondary index</a> defined
on them.</p><p>Not all relations are allowed in a query. For instance,
non-equal relations (where <code>IN</code> is considered as an equal relation)
on a partition key is only supported if the partitioner for the keyspace is an
ordered one. Moreover, for a given partition key, the clustering keys induce an
ordering of rows and relations on them is restricted to the relations that
allow to select a <strong>contiguous</strong> (for the ordering) set of rows.
For instance, given</p><pre class="sample"><pre>CREATE TABLE posts (
userid text,
blog_title text,
posted_at timestamp,
@@ -218,6 +218,7 @@ SELECT COUNT(*) FROM users;
</pre></pre><p>The following query is allowed:</p><pre
class="sample"><pre>SELECT entry_title, content FROM posts WHERE userid='john
doe' AND blog_title='John's Blog' AND posted_at >= 2012-01-01 AND posted_at
< 2012-01-31
</pre></pre><p>But the following one is not, as it does not select a
contiguous set of rows (and we suppose no secondary indexes are set):</p><pre
class="sample"><pre>// Needs a blog_title to be set to select ranges of
posted_at
SELECT entry_title, content FROM posts WHERE userid='john doe' AND posted_at
>= 2012-01-01 AND posted_at < 2012-01-31
+</pre></pre><p>When specifying relations, the <code>TOKEN</code> function can
be used on the <code>PARTITION KEY</code> column to query. In that case, rows
will be selected based on the token of their <code>PARTITION_KEY</code> rather
than on the value (note that the token of a key depends on the partitioner in
use, and that in particular the RandomPartitioner won’t yeld a meaningful
order). Example:</p><pre class="sample"><pre>SELECT * FROM posts WHERE
token(userid) > token('tom') AND token(userid) < token('bob')
</pre></pre><h4 id="selectOrderBy"><code><order-by></code></h4><p>The
<code>ORDER BY</code> option allows to select the order of the returned
results. It takes as argument a list of column names along with the order for
the column (<code>ASC</code> for ascendant and <code>DESC</code> for
descendant, omitting the order being equivalent to <code>ASC</code>). Currently
the possible orderings are limited (which depends on the table <a
href="#createTableOptions"><code>CLUSTERING ORDER</code></a>):</p><ul><li>if
the table has been defined without any specific <code>CLUSTERING ORDER</code>,
then then allowed orderings are the order induced by the clustering key and the
reverse of that one.</li><li>otherwise, the orderings allowed are the order of
the <code>CLUSTERING ORDER</code> option and the reversed one.</li></ul><h4
id="selectOther">Other options</h4><p>The <a href="#consistency">consistency
level</a> of a query can be set as for data manipulation statements using the
<code
>USING CONSISTENCY</code> keywords.</p><p>The <code>LIMIT</code> option to a
><code>SELECT</code> statement limits the number of rows returned by a query.
><code>LIMIT</code> defaults to 10,000 when left unset.</p><h2 id="types">Data
>Types</h2><p>CQL supports a rich set of native data types for columns defined
>in a table. On top of those native types, users can also provide custom
>types (through a JAVA class extending <code>AbstractType</code> loadable by
>Cassandra). The syntax of types is thus:</p><pre
>class="syntax"><pre><type> ::= <native_type>
| <string> // Used for custom types. The fully-qualified
name of a JAVA class
