Repository: cassandra Updated Branches: refs/heads/cassandra-2.0 d5a9c9254 -> 427fdd476
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/cassandra-2.0 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@
