-
Notifications
You must be signed in to change notification settings - Fork 9
CQL Executors
Gatling DSE provides multiple CQL Executors that provide different features needed for different query types. Most of the
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.
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()
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 inexecuteNamed()
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()
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()
allows for a SimpleStatement to be sent to the cluster with no bound parameters or string replacements.
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.
Getting Started
Feeds
Fetching Base Data
Load Generators
Simulations
- CQL Executors
- Simulation Writing Shortcuts
- Using Custom ClusterBuilder Settings
- Using Client to Node SSL
Advanced Topics
- Dependent Queries
- Using Graphite and Grafana
- Debugging Simulations
- Adjusting input from Feed Before Executing a Query
Archived (v1.0) Topics