git commit: Rename clustering keys to clustering columns in doc

2013-09-05 Thread slebresne
Updated Branches:
  refs/heads/cassandra-1.2 c49ad3ccf - 1f6844261


Rename clustering keys to clustering columns in doc


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/1f684426
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/1f684426
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/1f684426

Branch: refs/heads/cassandra-1.2
Commit: 1f6844261a83d48724be8fd172b7bf3a9018607a
Parents: c49ad3c
Author: Sylvain Lebresne sylv...@datastax.com
Authored: Thu Sep 5 16:35:18 2013 +0200
Committer: Sylvain Lebresne sylv...@datastax.com
Committed: Thu Sep 5 16:35:18 2013 +0200

--
 doc/cql3/CQL.textile | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/1f684426/doc/cql3/CQL.textile
--
diff --git a/doc/cql3/CQL.textile b/doc/cql3/CQL.textile
index bb9a632..168a05d 100644
--- a/doc/cql3/CQL.textile
+++ b/doc/cql3/CQL.textile
@@ -281,7 +281,7 @@ h4(#createTablepartitionClustering). Partition key and 
clustering
 
 In CQL, the order in which columns are defined for the @PRIMARY KEY@ matters. 
The first column of the key is called the __partition key__. It has the 
property that all the rows sharing the same partition key (even across table in 
fact) are stored on the same physical node. Also, insertion/update/deletion on 
rows sharing the same partition key for a given table are performed 
__atomically__ and in __isolation__. Note that it is possible to have a 
composite partition key, i.e. a partition key formed of multiple columns, using 
an extra set of parentheses to define which columns forms the partition key.
 
-The remaining columns of the @PRIMARY KEY@ definition, if any, are called 
__clustering keys__. On a given physical node, rows for a given partition key 
are stored in the order induced by the clustering keys, making the retrieval of 
rows in that clustering order particularly efficient (see a 
href=#selectStmtttSELECT/tt/a).
+The remaining columns of the @PRIMARY KEY@ definition, if any, are called 
__clustering columns. On a given physical node, rows for a given partition key 
are stored in the order induced by the clustering columns, making the retrieval 
of rows in that clustering order particularly efficient (see a 
href=#selectStmtttSELECT/tt/a).
 
 h4(#createTableOptions). @option@
 
@@ -360,7 +360,7 @@ p.
 The @ALTER@ statement is used to manipulate table definitions. It allows to 
add new columns, drop existing ones, change the type of existing columns, or 
update the table options. As for table creation, @ALTER COLUMNFAMILY@ is 
allowed as an alias for @ALTER TABLE@.
 
 The @tablename@ is the table name optionally preceded by the keyspace name.  
The @instruction@ defines the alteration to perform:
-* @ALTER@: Update the type of a given defined column. Note that the type of 
the clustering keys:#createTablepartitionClustering cannot be modified as it 
induces the on-disk ordering of rows. Columns on which a secondary 
index:#createIndexStmt is defined have the same restriction. Other columns are 
free from those restrictions (no validation of existing data is performed), but 
it is usually a bad idea to change the type to a non-compatible one, unless no 
data have been inserted for that column yet, as this could confuse CQL 
drivers/tools.
+* @ALTER@: Update the type of a given defined column. Note that the type of 
the clustering columns:#createTablepartitionClustering cannot be modified as 
it induces the on-disk ordering of rows. Columns on which a secondary 
index:#createIndexStmt is defined have the same restriction. Other columns are 
free from those restrictions (no validation of existing data is performed), but 
it is usually a bad idea to change the type to a non-compatible one, unless no 
data have been inserted for that column yet, as this could confuse CQL 
drivers/tools.
 * @ADD@: Adds a new column to the table. The @identifier@ for the new column 
must not conflict with an existing column. Moreover, columns cannot be added to 
tables defined with the @COMPACT STORAGE@ option.
 * @WITH@: Allows to update the options of the table. The supported 
@option@:#createTableOptions (and syntax) are the same as for the @CREATE 
TABLE@ statement except that @COMPACT STORAGE@ is not supported. Note that 
setting any @compaction@ sub-options has the effect of erasing all previous 
@compaction@ options, so you  need to re-specify all the sub-options if you 
want to keep them. The same note applies to the set of @compression@ 
sub-options.
 
@@ -634,7 +634,7 @@ h4(#selectWhere). @where-clause@
 
 The @where-clause@ specifies which rows must be queried. It is composed of 
relations on the columns that are part of the @PRIMARY KEY@ 

[1/2] git commit: Rename clustering keys to clustering columns in doc

2013-09-05 Thread slebresne
Updated Branches:
  refs/heads/cassandra-2.0 edc753127 - 12671160b


Rename clustering keys to clustering columns in doc


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/1f684426
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/1f684426
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/1f684426

Branch: refs/heads/cassandra-2.0
Commit: 1f6844261a83d48724be8fd172b7bf3a9018607a
Parents: c49ad3c
Author: Sylvain Lebresne sylv...@datastax.com
Authored: Thu Sep 5 16:35:18 2013 +0200
Committer: Sylvain Lebresne sylv...@datastax.com
Committed: Thu Sep 5 16:35:18 2013 +0200

--
 doc/cql3/CQL.textile | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/1f684426/doc/cql3/CQL.textile
--
diff --git a/doc/cql3/CQL.textile b/doc/cql3/CQL.textile
index bb9a632..168a05d 100644
--- a/doc/cql3/CQL.textile
+++ b/doc/cql3/CQL.textile
@@ -281,7 +281,7 @@ h4(#createTablepartitionClustering). Partition key and 
clustering
 
 In CQL, the order in which columns are defined for the @PRIMARY KEY@ matters. 
The first column of the key is called the __partition key__. It has the 
property that all the rows sharing the same partition key (even across table in 
fact) are stored on the same physical node. Also, insertion/update/deletion on 
rows sharing the same partition key for a given table are performed 
__atomically__ and in __isolation__. Note that it is possible to have a 
composite partition key, i.e. a partition key formed of multiple columns, using 
an extra set of parentheses to define which columns forms the partition key.
 
-The remaining columns of the @PRIMARY KEY@ definition, if any, are called 
__clustering keys__. On a given physical node, rows for a given partition key 
are stored in the order induced by the clustering keys, making the retrieval of 
rows in that clustering order particularly efficient (see a 
href=#selectStmtttSELECT/tt/a).
+The remaining columns of the @PRIMARY KEY@ definition, if any, are called 
__clustering columns. On a given physical node, rows for a given partition key 
are stored in the order induced by the clustering columns, making the retrieval 
of rows in that clustering order particularly efficient (see a 
href=#selectStmtttSELECT/tt/a).
 
 h4(#createTableOptions). @option@
 
@@ -360,7 +360,7 @@ p.
 The @ALTER@ statement is used to manipulate table definitions. It allows to 
add new columns, drop existing ones, change the type of existing columns, or 
update the table options. As for table creation, @ALTER COLUMNFAMILY@ is 
allowed as an alias for @ALTER TABLE@.
 
 The @tablename@ is the table name optionally preceded by the keyspace name.  
The @instruction@ defines the alteration to perform:
-* @ALTER@: Update the type of a given defined column. Note that the type of 
the clustering keys:#createTablepartitionClustering cannot be modified as it 
induces the on-disk ordering of rows. Columns on which a secondary 
index:#createIndexStmt is defined have the same restriction. Other columns are 
free from those restrictions (no validation of existing data is performed), but 
it is usually a bad idea to change the type to a non-compatible one, unless no 
data have been inserted for that column yet, as this could confuse CQL 
drivers/tools.
+* @ALTER@: Update the type of a given defined column. Note that the type of 
the clustering columns:#createTablepartitionClustering cannot be modified as 
it induces the on-disk ordering of rows. Columns on which a secondary 
index:#createIndexStmt is defined have the same restriction. Other columns are 
free from those restrictions (no validation of existing data is performed), but 
it is usually a bad idea to change the type to a non-compatible one, unless no 
data have been inserted for that column yet, as this could confuse CQL 
drivers/tools.
 * @ADD@: Adds a new column to the table. The @identifier@ for the new column 
must not conflict with an existing column. Moreover, columns cannot be added to 
tables defined with the @COMPACT STORAGE@ option.
 * @WITH@: Allows to update the options of the table. The supported 
@option@:#createTableOptions (and syntax) are the same as for the @CREATE 
TABLE@ statement except that @COMPACT STORAGE@ is not supported. Note that 
setting any @compaction@ sub-options has the effect of erasing all previous 
@compaction@ options, so you  need to re-specify all the sub-options if you 
want to keep them. The same note applies to the set of @compression@ 
sub-options.
 
@@ -634,7 +634,7 @@ h4(#selectWhere). @where-clause@
 
 The @where-clause@ specifies which rows must be queried. It is composed of 
relations on the columns that are part of the @PRIMARY KEY@ 

[1/3] git commit: Rename clustering keys to clustering columns in doc

2013-09-05 Thread slebresne
Updated Branches:
  refs/heads/trunk a17fac984 - a9005cbb5


Rename clustering keys to clustering columns in doc


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/1f684426
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/1f684426
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/1f684426

Branch: refs/heads/trunk
Commit: 1f6844261a83d48724be8fd172b7bf3a9018607a
Parents: c49ad3c
Author: Sylvain Lebresne sylv...@datastax.com
Authored: Thu Sep 5 16:35:18 2013 +0200
Committer: Sylvain Lebresne sylv...@datastax.com
Committed: Thu Sep 5 16:35:18 2013 +0200

--
 doc/cql3/CQL.textile | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/1f684426/doc/cql3/CQL.textile
--
diff --git a/doc/cql3/CQL.textile b/doc/cql3/CQL.textile
index bb9a632..168a05d 100644
--- a/doc/cql3/CQL.textile
+++ b/doc/cql3/CQL.textile
@@ -281,7 +281,7 @@ h4(#createTablepartitionClustering). Partition key and 
clustering
 
 In CQL, the order in which columns are defined for the @PRIMARY KEY@ matters. 
The first column of the key is called the __partition key__. It has the 
property that all the rows sharing the same partition key (even across table in 
fact) are stored on the same physical node. Also, insertion/update/deletion on 
rows sharing the same partition key for a given table are performed 
__atomically__ and in __isolation__. Note that it is possible to have a 
composite partition key, i.e. a partition key formed of multiple columns, using 
an extra set of parentheses to define which columns forms the partition key.
 
-The remaining columns of the @PRIMARY KEY@ definition, if any, are called 
__clustering keys__. On a given physical node, rows for a given partition key 
are stored in the order induced by the clustering keys, making the retrieval of 
rows in that clustering order particularly efficient (see a 
href=#selectStmtttSELECT/tt/a).
+The remaining columns of the @PRIMARY KEY@ definition, if any, are called 
__clustering columns. On a given physical node, rows for a given partition key 
are stored in the order induced by the clustering columns, making the retrieval 
of rows in that clustering order particularly efficient (see a 
href=#selectStmtttSELECT/tt/a).
 
 h4(#createTableOptions). @option@
 
@@ -360,7 +360,7 @@ p.
 The @ALTER@ statement is used to manipulate table definitions. It allows to 
add new columns, drop existing ones, change the type of existing columns, or 
update the table options. As for table creation, @ALTER COLUMNFAMILY@ is 
allowed as an alias for @ALTER TABLE@.
 
 The @tablename@ is the table name optionally preceded by the keyspace name.  
The @instruction@ defines the alteration to perform:
-* @ALTER@: Update the type of a given defined column. Note that the type of 
the clustering keys:#createTablepartitionClustering cannot be modified as it 
induces the on-disk ordering of rows. Columns on which a secondary 
index:#createIndexStmt is defined have the same restriction. Other columns are 
free from those restrictions (no validation of existing data is performed), but 
it is usually a bad idea to change the type to a non-compatible one, unless no 
data have been inserted for that column yet, as this could confuse CQL 
drivers/tools.
+* @ALTER@: Update the type of a given defined column. Note that the type of 
the clustering columns:#createTablepartitionClustering cannot be modified as 
it induces the on-disk ordering of rows. Columns on which a secondary 
index:#createIndexStmt is defined have the same restriction. Other columns are 
free from those restrictions (no validation of existing data is performed), but 
it is usually a bad idea to change the type to a non-compatible one, unless no 
data have been inserted for that column yet, as this could confuse CQL 
drivers/tools.
 * @ADD@: Adds a new column to the table. The @identifier@ for the new column 
must not conflict with an existing column. Moreover, columns cannot be added to 
tables defined with the @COMPACT STORAGE@ option.
 * @WITH@: Allows to update the options of the table. The supported 
@option@:#createTableOptions (and syntax) are the same as for the @CREATE 
TABLE@ statement except that @COMPACT STORAGE@ is not supported. Note that 
setting any @compaction@ sub-options has the effect of erasing all previous 
@compaction@ options, so you  need to re-specify all the sub-options if you 
want to keep them. The same note applies to the set of @compression@ 
sub-options.
 
@@ -634,7 +634,7 @@ h4(#selectWhere). @where-clause@
 
 The @where-clause@ specifies which rows must be queried. It is composed of 
relations on the columns that are part of the @PRIMARY KEY@ and/or have a