Skip to content

CQL Executors

Brad Vernon edited this page Oct 16, 2017 · 6 revisions

Gatling DSE provides multiple CQL Executors that provide different features needed for different query types. Most of the

executeNamed

executeNamed() is the executor that should be used by default as it auto-populates the prepared statement query values based on the named parameters present in the query and the Gatling User session populated by the Feeds used.

If the query builder being used in the Action is:

private def writeSpecBase = QueryBuilder.insertInto(keyspace, tables.specs)
    .value("spec_code", raw(":spec_code")),
    .value("timestamp", raw(":timestamp")),
    .value("event_type", raw(":event_type")),
    .value("event_task", raw(":event_task")),

with a feed of

Map(
    "spec_code" -> System.nanoTime().toString.takeRight(12),
    "timestamp" -> UUIDs.timeBased(),
    "event_type" -> "RUN",
    "event_task" -> "THINGS"
)

using the following CQL execution

exec(
    cql("CreateSpec").executeNamed(queries.writeSpec)
)

Gatling DSE will auto match the query columns to the Gatling session variable. For example the spec_code found in the query will be populated with the results of the Map key spec_code and have a value of System.nanoTime().toString.takeRight(12).

In order to use this executor your feed parameter names from a map or a csv/json must match the column name found in the prepared query and must be be all lowercase as the DataStax driver returns all column names in lowercase format. It's highly recommended during the creation of your table schema lowercase characters and _ are used instead of camelCase format.

Note: This execution will also work with prepared queries using ? for the value, but named parameters are recommended for easier understanding if the query is logged or shown to a customer or developer.

executePreparedBatch

executePrepared() enables multiple prepared statements to be added to the same batch query. The function takes an Array of prepared statements used in the executeNamed() where the prepared statements columns are auto populated based on matching query and session parameter names.

executePrepared

executePrepared() is most valuable when you want to explicitly set the order of your parameters as it uses the withParams(List(....)) function and the List passed to it to set the query param values by parameter order rather than by name. This allows for using any Gatling session variable name to map to any query param/column wanted, but is rarely required.

Sub-Functions

executePrepared() as the following methods to change the parameters being bound to the prepared statement:

  • .withSessionParams() - alias for the same behavior in executeNamed() where all matching session params to the query are auto bound
  • .withParams(List(....)) - provide a list of session keys to be bound in order based on the prepared statement
  • .withParams("${param1}", "${param2},...) - provide a list of params in order to be bound to the prepared statement in the Gatling replacement format

executeCQL

executeCql() This option includes special Gatling enabled replacements allowing for on query time parameter replacements based on the Gatling session key matching the parameter name. For example ... WHERE pkey='${partitionKey}'.. will be rendered as ... WHERE pkey='theKey'.. where partitionKey in the Gatling session equals theKey

Note: this should almost never be used in Gatling simulations unless there is a need to send non-prepared statements to emulate a customers queries or show difference of performance between a prepared or non-prepared statement.

executeStatement()

executeStatement() allows for a SimpleStatement to be sent to the cluster with no bound parameters or string replacements.

executeCustomPayload()

executeCustomPayload() allows for a SimpleStatement along with a custom serialized payload to be sent to the cluster. The custom payload key must already be in the Gatling session via a custom feeder before running to properly bind to the query.