natas_hw
/
cassandra
mirror of https://github.com/apache/cassandra
0
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Merge branch 'cassandra-1.2' into cassandra-2.0 

Conflicts:
	CHANGES.txt
This commit is contained in:
Tyler Hobbs 2014-03-19 11:40:40 -05:00
parent 32c15c2fb0 7e870018dc
commit c80f61b682
2 changed files with 16 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
CHANGES.txt
View File

@ -25,6 +25,7 @@
* Extend triggers to support CAS updates (CASSANDRA-6882)
* Static columns with IF NOT EXISTS don't always work as expected (CASSANDRA-6873)
Merged from 1.2:
* Add UNLOGGED, COUNTER options to BATCH documentation (CASSANDRA-6816)
* add extra SSL cipher suites (CASSANDRA-6613)
* fix nodetool getsstables for blob PK (CASSANDRA-6803)

19
doc/cql3/CQL.textile
View File

@ -581,7 +581,7 @@ h3(#batchStmt). BATCH
__Syntax:__
bc(syntax)..
<batch-stmt> ::= BEGIN BATCH
<batch-stmt> ::= BEGIN ( UNLOGGED | COUNTER ) BATCH
( USING <option> ( AND <option> )* )?
<modification-stmt> ( ';' <modification-stmt> )*
APPLY BATCH
@ -602,11 +602,22 @@ BEGIN BATCH
DELETE name FROM users WHERE userid = 'user1';
APPLY BATCH;
The @BATCH@ statement group multiple modification statements (insertions/updates and deletions) into a single statement. It mainly serves two purposes:
# it saves network round-trips between the client and the server (and sometimes between the server coordinator and the replicas) when batching multiple updates.
# all updates in a @BATCH@ belonging to a given partition key are performed atomically and in isolation
The @BATCH@ statement group multiple modification statements (insertions/updates and deletions) into a single statement. It serves several purposes:
# It saves network round-trips between the client and the server (and sometimes between the server coordinator and the replicas) when batching multiple updates.
# All updates in a @BATCH@ belonging to a given partition key are performed in isolation.
# By default, all operations in the batch are performed atomically. See the notes on "@UNLOGGED@":#unloggedBatch for more details.
Note however that the @BATCH@ statement only allows @UPDATE@, @INSERT@ and @DELETE@ statements and is _not_ a full analogue for SQL transactions.
h4(#unloggedBatch). @UNLOGGED@
By default, Cassandra uses a batch log to ensure all operations in a batch are applied atomically. (Note that the operations are still only isolated within a single partition.)
There is a performance penalty for batch atomicity when a batch spans multiple partitions. If you do not want to incur this penalty, you can tell Cassandra to skip the batchlog with the @UNLOGGED@ option. If the @UNLOGGED@ option is used, operations are only atomic within a single partition.
h4(#counterBatch). @COUNTER@
Use the @COUNTER@ option for batched counter updates. Unlike other updates in Cassandra, counter updates are not idempotent.
h4(#batchOptions). @<option>@
@BATCH@ supports both the @TIMESTAMP@ option, with similar semantic to the one described in the "@UPDATE@":#updateOptions statement (the timestamp applies to all the statement inside the batch). However, if used, @TIMESTAMP@ *must not* be used in the statements within the batch.