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
UnsupportedFeatureExceptionwhen 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, getOutgoingPayload, getReadTimeoutMillis, getRetryPolicy, getSerialConsistencyLevel, isIdempotent, isTracing, setConsistencyLevel, setDefaultTimestamp, setFetchSize, setIdempotent, setOutgoingPayload, setPagingState, setPagingState, setPagingStateUnsafe, setReadTimeoutMillis, setRetryPolicy
public BatchStatement(BatchStatement.Type batchType)
batchType- the type of batch.
public BatchStatement add(Statement statement)
statementcan be any
Statement. It is allowed to mix
BoundStatementin the same
BatchStatementin particular. Adding another
BatchStatementis also allowed for convenience and is equivalent to adding all the
Statementcontained in that other
BatchStatement. Due to a protocol-level limitation, adding a
RegularStatementwith named values is currently not supported; an
IllegalArgumentwill be thrown. When adding a
BoundStatement, all of its values must be set, otherwise an
IllegalStateExceptionwill be thrown when submitting the batch statement. See
BoundStatementfor more details, in particular how to handle
nullvalues. Please note that the options of the added Statement (all those defined directly by the
Statementclass: consistency level, fetch size, tracing, ...) will be ignored for the purpose of the execution of the Batch. Instead, the options used are the one of this
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).
IllegalArgumentException- if adding a regular statement that uses named values.
public BatchStatement addAll(Iterable<? extends Statement> statements)
add(com.datastax.driver.core.Statement)on all the statements from
statements- the statements to add.
public Collection<Statement> getStatements()
public BatchStatement clear()
public int size()
public BatchStatement setSerialConsistencyLevel(ConsistencyLevel serialConsistency)
UnsupportedFeatureExceptionwhen 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(ProtocolVersion protocolVersion, CodecRegistry codecRegistry)
null. The routing key is an hint used for token-aware routing (see
TokenAwarePolicy), and 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.
protocolVersion- the protocol version that will be used if the actual implementation needs to serialize something to compute the key.
codecRegistry- the codec registry that will be used if the actual implementation needs to serialize something to compute this key.
public String getKeyspace()
null. Firstly, some queries do not operate inside a keyspace: keyspace creation,
USEqueries, 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
USEquery (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 return
null(or even a bogus keyspace name) will never cause the query to fail.