public class BatchStatement extends Statement
Statement so they get executed as
a batch.
Note: BatchStatement is not supported with the native protocol version 1: you
will get an UnsupportedProtocolVersionException when submitting one if
version 1 of the protocol is in use (i.e. if you've force version 1 through
Cluster.Builder.withProtocolVersion(int) or you use Cassandra 1.2). Note
however that you can still use CQL Batch statements
even with the protocol version 1.
| Modifier and Type | Class and Description |
|---|---|
static class |
BatchStatement.Type
The type of batch to use.
|
idempotent| Constructor and Description |
|---|
BatchStatement()
Creates a new
LOGGED batch statement. |
BatchStatement(BatchStatement.Type batchType)
Creates a new batch statement of the provided type.
|
| Modifier and Type | Method and Description |
|---|---|
BatchStatement |
add(Statement statement)
Adds a new statement to this batch.
|
BatchStatement |
addAll(Iterable<? extends Statement> statements)
Adds multiple statements to this batch.
|
BatchStatement |
clear()
Clears this batch, removing all statements added so far.
|
String |
getKeyspace()
Returns the keyspace this query operates on.
|
ByteBuffer |
getRoutingKey()
Returns the routing key (in binary raw form) to use for token aware
routing of this query.
|
Collection<Statement> |
getStatements()
The statements that have been added to this batch so far.
|
Statement |
setSerialConsistencyLevel(ConsistencyLevel serialConsistency)
Throws an
UnsupportedOperationException as setting the serial consistency is
currently not supported for protocol batches by Cassandra. |
int |
size()
Returns the number of elements in this batch.
|
disableTracing, enableTracing, getConsistencyLevel, getFetchSize, getRetryPolicy, getSerialConsistencyLevel, isIdempotent, isTracing, setConsistencyLevel, setFetchSize, setIdempotent, setPagingState, setPagingStateUnsafe, setRetryPolicypublic BatchStatement()
LOGGED batch statement.public BatchStatement(BatchStatement.Type batchType)
batchType - the type of batch.public BatchStatement add(Statement statement)
Note that statement can be any Statement. It is allowed to mix
RegularStatement and BoundStatement in the same
BatchStatement in particular. Adding another BatchStatement
is also allowed for convenient and is equivalent to adding all the Statement
contained in that other BatchStatement.
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
of this BatchStatement object.
statement - the new statement to add.IllegalStateException - if adding the new statement means that this
BatchStatement has 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
from statements.
statements - the statements to add.public Collection<Statement> getStatements()
public BatchStatement clear()
BatchStatement.public int size()
public Statement setSerialConsistencyLevel(ConsistencyLevel serialConsistency)
UnsupportedOperationException as setting the serial consistency is
currently not supported for protocol batches by Cassandra.
The current version of the protocol uses does not allow to provide a serial consistency level for protocol batches (the batch created through this class). This is fixed by the protocol version 3 that will be part of Cassandra 2.1 and will be supported by the driver version 2.1. Until then, protocol batch with conditions will 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.
setSerialConsistencyLevel in class StatementserialConsistency - the serial consistency levelUnsupportedOperationException.UnsupportedOperationException - see above.public ByteBuffer getRoutingKey()
Statement
The routing key is optional in that implementers are free to
return 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.
getRoutingKey in class Statementnull.public String getKeyspace()
Statement
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, USE queries,
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 USE query
(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.
getKeyspace in class Statementnull.Copyright © 2012–2015. All rights reserved.