When executing a conditional statement, the `ResultSet` will contain a single `Row` with a

column named "applied" of type boolean. This tells whether the conditional statement was

successful or not.

The driver provides a convenience method [wasApplied] to check this on the result set directly:

ResultSet rset = session.execute(conditionalStatement);

rset.wasApplied();

You may also inspect the value yourself:

ResultSet rset = session.execute(conditionalStatement);

Row row = rset.one();

row.getBool(0); // this is equivalent row.getBool("applied")

Note that, unlike manual inspection, `wasApplied` does not consume the first row.

[wasApplied]: http://docs.datastax.com/en/drivers/java/2.1/com/datastax/driver/core/ResultSet.html#wasApplied--

Starting with Cassandra 2.0, normal statements (that is non-prepared statements) do

not need to concatenate parameter values inside a query string. Instead you can use

`?` markers and provide the values separately:

session.execute( "INSERT INTO contacts (email, firstname, lastname)

VALUES (?, ?, ?)", "clint.barton@hawkeye.com", "Barney", "Barton");

See [Simple statements](../manual/statements/simple/) for more information.

A parameterized statement sends the values of parameters separate from the query

(similar to the way a prepared statement does) as bytes so there is no need to escape

parameters.

The only similarity between a parameterized statement and a prepared statement is in

the way that the parameters are sent. The difference is that a prepared statement:

* is already known on the cluster side (it has been compiled and there is an execution

plan available for it) which leads to better performance

* sends only the statement id and its parameters (thus reducing the amount of data sent

to the cluster)

See [Prepared statements](../manual/statements/prepared/) for more information.

Yes. A batch can include both bound statements and simple statements:

PreparedStatement ps = session.prepare( "INSERT INTO contacts (email, firstname, lastname)

VALUES (?, ?, ?)");

BatchStatement batch = new BatchStatement();

batch.add(ps.bind(...));

batch.add(ps.bind(...));

batch.add(new SimpleStatement( "INSERT INTO contacts (email, firstname, lastname) VALUES (?, ?, ?)", ...));

session.execute(batch);

If you need to access the raw bytes of a text column, call the

`Row.getBytesUnsafe("columnName")` method.

Trying to use `Row.getBytes("columnName")` for the same purpose results in an

exception, as the `getBytes` method can only be used if the column has the CQL type `BLOB`.

Considering the following query:

UPDATE clickstream SET clicks = clicks + 1 WHERE userid = id;

To do this using `QueryBuilder`:

Statement query = QueryBuilder.update("clickstream")

.with(incr("clicks", 1)) // Use incr for counters

.where(eq("userid", id));

Use the `setFetchSize()` method on your `Statement` object. The fetch size controls

how many resulting rows are retrieved simultaneously (the goal being to avoid

loading too many results in memory for queries yielding large result sets).

Keep in mind that if your code iterates the `ResultSet` entirely, the driver may

run additional background queries to fetch the rest of the data. The fetch size

only affects what is retrieved at a time, not the overall number of rows.

See [Paging](../manual/paging/) for more information.

Basically, `LIMIT` controls the maximum number of results returned by the query,

while the `setFetchSize()` method controls the amount of data transferred at a time.

For example, if you limit is 30 and your fetch size is 10, the `ResultSet` will contain

30 rows, but under the hood the driver will perform 3 requests that will transfer 10

rows each.

See [Paging](../manual/paging/) for more information.