Repository: cassandra
Updated Branches:
  refs/heads/trunk d8490ccea -> f74063c6e


Document lack of order guarantees for BATCH statements

Patch by Tyler Hobbs, reviewed by Sylvain Lebresnse and Alex Popescu for
CASSANDRA-7123


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

Branch: refs/heads/trunk
Commit: 427fdd476a631b3850ecd643f71155a5b7dd2bf7
Parents: d5a9c92
Author: Tyler Hobbs <ty...@datastax.com>
Authored: Thu May 1 13:03:56 2014 -0500
Committer: Tyler Hobbs <ty...@datastax.com>
Committed: Thu May 1 13:03:56 2014 -0500

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


http://git-wip-us.apache.org/repos/asf/cassandra/blob/427fdd47/doc/cql3/CQL.textile
----------------------------------------------------------------------
diff --git a/doc/cql3/CQL.textile b/doc/cql3/CQL.textile
index f6208bf..bedd189 100644
--- a/doc/cql3/CQL.textile
+++ b/doc/cql3/CQL.textile
@@ -614,7 +614,11 @@ The @BATCH@ statement group multiple modification 
statements (insertions/updates
 # 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.
+
+Note that:
+* @BATCH@ statements may only contain @UPDATE@, @INSERT@ and @DELETE@ 
statements.
+* Batches are _not_ a full analogue for SQL transactions.
+* If a timestamp is not specified for each operation, then all operations will 
be applied with the same timestamp. Due to Cassandra's conflict resolution 
procedure in the case of "timestamp 
ties":http://wiki.apache.org/cassandra/FAQ#clocktie, operations may be applied 
in an order that is different from the order they are listed in the @BATCH@ 
statement. To force a particular operation ordering, you must specify 
per-operation timestamps.
 
 h4(#unloggedBatch). @UNLOGGED@
 

Reply via email to