public class BatchStatement extends Statement
Statementso they get executed as a batch.
Note: BatchStatement is not supported with the native protocol version 1: you
will get an
UnsupportedFeatureException when submitting one if
version 1 of the protocol is in use (i.e. if you've force version 1 through
Cluster.Builder.withProtocolVersion(com.datastax.driver.core.ProtocolVersion) or you use Cassandra 1.2). Note
however that you can still use CQL Batch statements
even with the protocol version 1.
Setting a BatchStatement's serial consistency level is only supported with the
native protocol version 3 or higher (see
|Modifier and Type||Class and Description|
The type of batch to use.
|Constructor and Description|
Creates a new
Creates a new batch statement of the provided type.
|Modifier and Type||Method and Description|
Adds a new statement to this batch.
Adds multiple statements to this batch.
Clears this batch, removing all statements added so far.
Returns the keyspace this query operates on.
Returns the routing key (in binary raw form) to use for token aware routing of this query.
The statements that have been added to this batch so far.
Sets the serial consistency level for the query.
Returns the number of elements in this batch.
disableTracing, enableTracing, getConsistencyLevel, getDefaultTimestamp, getFetchSize, getRetryPolicy, getSerialConsistencyLevel, isIdempotent, isTracing, setConsistencyLevel, setDefaultTimestamp, setFetchSize, setIdempotent, setOutgoingPayload, setPagingState, setPagingStateUnsafe, setRetryPolicy
public BatchStatement(BatchStatement.Type batchType)
batchType- the type of batch.
public BatchStatement add(Statement statement)
statement can be any
Statement. It is allowed to mix
BoundStatement in the same
BatchStatement in particular. Adding another
is also allowed for convenience and is equivalent to adding all the
contained in that other
When adding a
BoundStatement, all of its values must be set, otherwise an
IllegalStateException will be thrown when submitting the batch statement.
BoundStatement for more details, in particular how to handle
Please note that the options of the added Statement (all those defined directly by the
Statement class: consistency level, fetch size, tracing, ...) will be ignored
for the purpose of the execution of the Batch. Instead, the options used are the one
statement- the new statement to add.
IllegalStateException- if adding the new statement means that this
BatchStatementhas more than 65536 statements (since this is the maximum number of statements for a BatchStatement allowed by the underlying protocol).
public BatchStatement addAll(Iterable<? extends Statement> statements)
This is a shortcut method that calls
add(com.datastax.driver.core.Statement) on all the statements
statements- the statements to add.
public Collection<Statement> getStatements()
public BatchStatement clear()
public int size()
public BatchStatement setSerialConsistencyLevel(ConsistencyLevel serialConsistency)
This is only supported with version 3 or higher of the native protocol. If you call
this method when version 2 is in use, you will get an
when submitting the statement. With version 2, protocol batches with conditions
have their serial consistency level hardcoded to SERIAL; if you need to execute a batch
with LOCAL_SERIAL, you will have to use a CQL batch.
serialConsistency- the serial consistency level to set.
serialConsistencyis not one of
public ByteBuffer getRoutingKey()
The routing key is optional in that implementers are free to
null. The routing key is an hint used for token-aware routing (see
if provided should correspond to the binary value for the query
partition key. However, not providing a routing key never causes a query
to fail and if the load balancing policy used is not token aware, then
the routing key can be safely ignored.
public String getKeyspace()
Note that not all query specify on which keyspace they operate on, and
so this method can always return
null. Firstly, some queries do
not operate inside a keyspace: keyspace creation,
user creation, etc. Secondly, even query that operate within a keyspace
do not have to specify said keyspace directly, in which case the
currently logged in keyspace (the one set through a
(or through the use of
Cluster.connect(String))). Lastly, as
for the routing key, this keyspace information is only a hint for
token-aware routing (since replica placement depend on the replication
strategy in use which is a per-keyspace property) and having this method
null (or even a bogus keyspace name) will never cause the
query to fail.
Copyright © 2012–2015. All rights reserved.