Gatling JDBC Release 1.0.0

Although some weeks have already passed, I want to announce the release of Gatling JDBC 1.0.0. This Gatling extension can be used to performance-test JDBC within Gatling simulation. It is now available on Maven central and can be added easily to your build.sbt:

libraryDependencies += "de.codecentric" %% "gatling-jdbc" % "1.0.0"

It provides actions for basic SQL commands like

• Create table
• Drop table
• Select
• Insert
• Delete

Next to those, simple checks can be performed on the data received by selects. Before I show you some examples, I would like to give you some background on the extension.

Why Gatling JDBC?

In one of my earlier blog posts related to Gatling performance tests I showed how to extend Gatling. The example implementation for the blog post was a JDBC extension.

After the example project rested for a while, I was wondering if it should be published on Maven central. The project was working and in a better shape than my usual example projects. Obviously, I decided to push it to Maven Central and therefore make it available to a broader group of users.

To give you a feeling for how the library can be used, I want to show you some of the usages that have more than one way to be applied.

Usage

When implementing the extension, I followed the fluent API approach of Gatling as best as I could. Still, I wanted to keep as much flexibility as possible for the user. E.g. a select can be performed in two ways. Firstly:

exec(jdbc("selection")
  .select("*")
  .from("table")
)

to get the values of all columns. Alternatively:

exec(jdbc("selection")
  .select("id, num")
  .from("table")
)

to select only a limited amount of columns.

Creating tables and their columns using strings seemed disadvantageous. Columns have to have a name, a type and optionally constraints. Also, a table must consist of at least one column. Therefore, I decided to to make use of Scala’s type safety here. This was when the ColumnHelper was introduced. It provides helper functions to create columns and their attributes. This provides a way to have some safety but still enough freedom for the users. Creating a table with two columns looks like this:

import de.codecentric.gatling.jdbc.builder.column.ColumnHelper._
...
exec(jdbc("bar table")
      .create()
      .table("table")
      .columns(
        column(
          name("id"),
          dataType("INTEGER"),
          constraint("PRIMARY KEY")
        ),
        column(
          name("num"),
          dataType("INTEGER")
        )
      )
    )

As you can see, there are no constants or similar for data types and constraints. In order to avoid implementing translations for the different databases and adhering to every special case, using strings was again the simplest solution. That ways, the users can use all the data types and constraints the concrete database provides.

For insertions we can choose between using the implicit order of a table or to provide it explicitly. The former case looks like this:

exec(jdbc("insertion")
  .insert()
  .into("table")
  .values("${n}, ${n}")
)

Whereas the latter case looks like this:

exec(jdbc("insertion")
  .insert()
  .into("table (id, num)")
  .values("${n}, ${n}")
)

As before, using a simple string provided the greatest flexibility.

Since I only want to present the exceptional things here and not repeat the whole README, the last thing I want to show are the checks. Inspired by the checks Gatling’s HTTP module provides, the JDBC checks should provide at least a basic form of validation. For now, checks can only be appended to selects. The trait JdbcCheckSupport provides a method to create a simpleCheck. This method takes a function List[Map[String, Any]] => Boolean.
The list represents every row returned by a select and the map the different columns. If the function evaluates to true the check is successful.
If we have a select that returns only one row and if we want to check only one column, it can look like this:

import de.codecentric.gatling.jdbc.Predef._ // Predef extends JdbcCheckSupport
...
    exec(jdbc("selection")
      .select("num")
      .from("table1")
      .where("id=4")
      .check(simpleCheck(result => result.head("num") == 4))

I hope this gives you an impression of how to use the library. If you want to see more examples, take a look into the project . The classes that end with “Simulation” are example implementations.

What’s next?

Currently, I do not have a roadmap for the project. Since I have no idea how big the interest in JDBC performance testing is, I am curious about the feedback I will receive. So, if you have any suggestions or find any bugs, please feel free to let me know via GitHub . I will try to answer all requests as quickly as possible.