R2DBC

R2DBC 1.0 goes GA

Mon, 25 Apr 2022 13:00:00 +0000

Dear R2DBC Community,

On behalf of the entire community and everyone who contributed, it is my special honour to announce the general availability of the Reactive Relational Database Connectivity Specification version 1.0.0.RELEASE.

After 268 tickets and five years of work on the specification, R2DBC finally arrived at a state where we feel confident to publish a 1.0 version of the specification. Our previous releases 0.8 and 0.9 helped with incubation and validation of the spec to make sure we’re on the right path towards a reliable database connectivity specification. The huge success in adoption helped us to understand where R2DBC needs to go and it helped to build a community around our efforts.

Amongst other features, the specification contains the following highlighted features:

Driver SPI and TCK (Technology Compatibility Kit)
Integration with BLOB and CLOB types
Extensible Transaction Definitions
Plain and Parameterized Statements („Prepared Statements“)
Support for Stored Procedures/Server Side Functions along with IN and OUT Parameter bindings
Consumption of Update Counts, Rows, and Stored Procedure Results
Batch operations
Categorized Exceptions
ServiceLoader-based Driver Discovery
Connection URL scheme
Programmatic Configuration API

Special thanks go to the driver and implementor community for your discussions and help without whom it wouldn’t be possible to achieve a stable 1.0 specification state.

The previous 0.8 and 0.9 releases were accompanied with a release train BOM (Bill of Materials) for easier consumption. With the 1.0 release we no longer maintain a bill of materials to decouple specification development and to enable implementors to ship drivers and R2DBC libraries on their own pace. The 1.0 release defines a stable state for the foreseeable future and we expect driver vendors to upgrade to R2DBC 1.0 throughout the year.

This change in the release strategy removes the need to maintain an additional release train.

A few resources with details about this release:

Release artifacts

R2DBC Borca-RELEASE released

Fri, 04 Feb 2022 06:00:00 +0000

It is my pleasure to announce that, after more than two years of specification work, milestones and RCs we can finally conclude the efforts of R2DBC 0.9 with the Borca release train being generally available from Maven Central.

The release train bundles the R2DBC 0.9 specification and all compliant implementations within a release train by providing a bill of materials to ensure a consistent set of dependencies for your reactive SQL database workloads.

Specifically, this release train ships with:

io.r2dbc:r2dbc-spi:0.9.1.RELEASE - R2DBC SPI 0.9.1.RELEASE
io.r2dbc:r2dbc-h2:0.9.1.RELEASE - R2DBC H2 driver 0.9.1.RELEASE
org.mariadb:r2dbc-mariadb:1.1.1-rc - MariaDB R2DBC connector 1.1.1-rc
com.oracle.database.r2dbc:oracle-r2dbc:0.4.0 - Oracle R2DBC driver 0.4.0
io.r2dbc:r2dbc-pool:0.9.0.RELEASE - R2DBC Pool 0.9.0.RELEASE
org.postgresql:r2dbc-postgresql:0.9.0.RELEASE - R2DBC Postgres driver 0.9.0.RELEASE
io.r2dbc:r2dbc-proxy:0.9.0.RELEASE - R2DBC Proxy 0.9.0.RELEASE
io.r2dbc:r2dbc-mssql:0.9.0.RELEASE - R2DBC SQL Server driver 0.9.0.RELEASE

If you use Maven, you can add the following lines to your pom.xml:

<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>io.r2dbc</groupId>
      <artifactId>r2dbc-bom</artifactId>
      <version>Borca-RELEASE</version>
      <type>pom</type>
      <scope>import</scope>
    </dependency>
  </dependencies>
</dependencyManagement>

<dependencies>
  <dependency>
    <groupId>org.postgresql</groupId>
    <artifactId>r2dbc-postgres</artifactId>
  </dependency>
</dependencies>

With the transition of the Borca release train to GA, we plan to ship two final rounds of service releases for the Arabba release train (R2DBC 0.8) later this year before transitioning the Arabba release train into EOL mode after Q2/2022. Each implementation can decide whether they are going to ship maintenance releases supporting R2DBC 0.8. We are also working towards R2DBC 1.0 GA. The backlog is sorted and the 1.0 GA release is going to be a lighter revision of the specification where we iron out any last rough edges. R2DBC 1.0 is going to be the version that serves as reactive database integration spec for the foreseeable future.

R2DBC Arabba-SR12 released

Thu, 13 Jan 2022 06:00:00 +0000

On behalf of the community and everyone who contributed, we’re pleased to announce availability of R2DBC Arabba-SR12 available from Maven Central!

This service release ships the following modules:

Google Cloud Spanner Driver - 1.1.0 (com.google.cloud:cloud-spanner-r2dbc)
MariaDB connector - 1.0.3 (org.mariadb:r2dbc-mariadb)
H2 driver - 0.8.5.RELEASE (io.r2dbc:r2dbc-h2)
PostgreSQL driver - 0.8.11.RELEASE (io.r2dbc:r2dbc-postgresql)
R2DBC Pool - 0.8.8.RELEASE (io.r2dbc:r2dbc-pool)
SQL Server driver - 0.8.8.RELEASE (io.r2dbc:r2dbc-postgresql)

This is a maintenance release shipping with mostly bugfixes fixes, selected enhancements, and dependency upgrades. Check out the changelogs associated with each component.

We recommend version management by using R2DBC BOM as individual modules follow their own version number schedule.

If you use Maven, you can add the following lines to your pom.xml:

<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>io.r2dbc</groupId>
      <artifactId>r2dbc-bom</artifactId>
      <version>Arabba-SR12</version>
      <type>pom</type>
      <scope>import</scope>
    </dependency>
  </dependencies>
</dependencyManagement>

<dependencies>
  <dependency>
    <groupId>com.google.cloud</groupId>
    <artifactId>cloud-spanner-r2dbc</artifactId>
  </dependency>
</dependencies>

R2DBC 0.9 goes GA

Mon, 06 Dec 2021 09:00:00 +0000

Dear community,

It is my pleasure to announce the general availability of R2DBC 0.9.0.RELEASE from Maven Central!

This revision of the R2DBC specification has been in the works for roughly two years and ships numerous enhancements to the SPI and specification:

Extensible Transaction Definitions.
Improved Bind-Parameter Declaration
Consumption of OUT Parameters by introducing OutParameters. Row and OutParameters now share the common superinterface Readable.
Introduction of the Result.map(Function<Readable, T>) method.
Introduction of the Result.Segment API type hierarchy and Result.filter(Predicate<Segment>) and Result.flatMap(Function<Segment, Publisher<T>>) methods to consume arbitrary statement results.
Lifecycle support by introducing the Lifecycle interface.
Removal of generic type of ConnectionFactoryOptions.getValue(Option) and getRequiredValue(…).
Deprecate RowMetadata.getColumnNames() and introduce RowMetadata.contains(String) to simplify constraints and usage around column presence checks.
Support for Lock Wait and Statement Timeouts through Connection.setLockWaitTimeout(Duration) and Connection.setStatementTimeout(Duration) methods.

In order to make the specification consumable, R2DBC implementors can now pick up the specification and ship releases of their drivers. Looking forward, we expect a release train release (r2dbc-bom code name Borca-GA) in early February 2022. Until then, try out RC-level releases of R2DBC drivers and learn about the new and noteworthy:

A few resources with details about this release:

Release artifacts

Beyond this release, we prepare ourselves for the R2DBC 1.0 GA release in Q1/Q2 2022. Stay tuned.

R2DBC Arabba-SR11 released

Fri, 24 Sep 2021 06:00:00 +0000

On behalf of the community and everyone who contributed, we’re pleased to announce availability of R2DBC Arabba-SR11 available from Maven Central!

This service release ships the following modules:

R2DBC Specification - 0.8.6.RELEASE (io.r2dbc:r2dbc-spi)
Google Cloud Spanner Driver - 0.6.0 (com.google.cloud:cloud-spanner-r2dbc)
MariaDB connector - 1.0.2 (org.mariadb:r2dbc-mariadb)
PostgreSQL driver - 0.8.10.RELEASE (io.r2dbc:r2dbc-postgresql)
SQL Server driver - 0.8.7.RELEASE (io.r2dbc:r2dbc-postgresql)
R2DBC Proxy - 0.8.8.RELEASE (io.r2dbc:r2dbc-proxy)

This is a maintenance release shipping with mostly bugfixes fixes, selected enhancements, and dependency upgrades. Check out the changelogs associated with each component.

We recommend version management by using R2DBC BOM as individual modules follow their own version number schedule.

If you use Maven, you can add the following lines to your pom.xml:

<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>io.r2dbc</groupId>
      <artifactId>r2dbc-bom</artifactId>
      <version>Arabba-SR11</version>
      <type>pom</type>
      <scope>import</scope>
    </dependency>
  </dependencies>
</dependencyManagement>

<dependencies>
  <dependency>
    <groupId>org.mariadb</groupId>
    <artifactId>r2dbc-mariadb</artifactId>
  </dependency>
</dependencies>

R2DBC 0.9.0.M2 available (Borca-M2)

Tue, 31 Aug 2021 14:00:00 +0000

R2DBC 0.9.0.M2 available (Borca-M2)

Dear R2DBC Community,

We’re excited to announce that the majority of R2DBC implementations has upgraded to R2DBC 0.9 M2. As of today, the following libraries comply with the specification:

oracle-r2dbc 0.3.0
r2dbc-h2 0.9.0.M1
r2dbc-mariadb 1.1.0-beta
r2dbc-mssql 0.9.0.M2
r2dbc-pool 0.9.0.M2
r2dbc-postgres 0.9.0.M2
r2dbc-proxy 0.9.0.M2

You can consume drivers and the specification artifacts either individually or through a version-managed bill of materials:

If you use Maven, you can add the following lines to your pom.xml:

<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>io.r2dbc</groupId>
      <artifactId>r2dbc-bom</artifactId>
      <version>Borca-M2</version>
      <type>pom</type>
      <scope>import</scope>
    </dependency>
  </dependencies>
</dependencyManagement>

<dependencies>
  <dependency>
    <groupId>com.oracle.database.r2dbc</groupId>
    <artifactId>oracle-r2dbc</artifactId>
  </dependency>
</dependencies>

This release is a major leap forward as the specification version 0.9 defines fine-grained interaction for parameter specifications, out-parameter consumption (typically used for stored procedures), and consumption of individual result segments using a single operator.

Let’s have a detailed look at the most significant changes.

Consumption of OUT Parameters

The initial draft of R2DBC assumed that stored procedures are out of scope because they were rarely used. While the specification evolved, we learned that stored procedures are still heavily leveraged for workloads that are heavily tied to the database. We decided to provide means to call stored procedures properly by introducing the Parameters abstraction and consumption of results of stored procedures by introducing OutParameters.

The Parameters abstraction was introduced with the previous milestone. OutParameters is specified in this milestone. It essentially provides access by name and index to out parameters returned from a stored procedure invocation. To consume out parameters, callers need to:

Register OUT parameter bindings
Consume out parameters through the map(…) or flatMap(…) operator.

Consider the following stored procedure (using Microsoft SQL Server):

CREATE PROCEDURE say_hello
    @TheName nvarchar(50),
    @Greeting nvarchar(255) OUTPUT
AS

    SET NOCOUNT ON;  
    SET @Greeting = CONCAT('Hello ', @TheName)

This procedure concatenates Hello with the input parameter @TheName and returns @Greeting as out parameter.

The invocation is straight forward by calling say_hello through SQL and two parameters. Note that @Greeting is bound as out parameter with a specific data type of VARCHAR.

connection.createStatement("EXEC say_hello @P0, @Greeting OUTPUT")
    .bind("@P0", "Walter")
    .bind("@Greeting", Parameters.out(R2dbcType.VARCHAR))
    .execute()
    .flatMap(it -> it.map((readable) -> {
        return readable.get(0);
    }));

You might be surprised by seeing the map(…) operator accepting a Function<Readable, T> instead of BiFunction<Row, RowMetadata, T>. With the introduction of OutParameters, we introduced Readable as superinterface for OutParameters and Row that defines get(…) methods for both subtypes. Both Row and OutParameters follow the same semantics of by-name and by-index access to statement results so we introduced map(Function<Readable, T>) for easier consumption of tabular and stored procedure results.

OutParameters and Row define getMetadata methods in case you’re interested in out parameters/column metadata.

Consuming individual segments

Imagine a client that passes-thru SQL without being aware of what kind of result it is going to produce. Result.map(…) and Result.getRowsUpdated() have been the only two methods to consume results and both are mutually exclusive. Consuming rows doesn’t allow for access to update counts and vice versa.

This release removes this limitation by introducing filter and flatMap methods that conceptually turn Result into a Publisher<Segment>. Segment is a type hierarchy to represent the individual result types that a statement can produce: Update counts, rows, out parameters, messages, and any vendor-specific types.

Consumers that are interested in all types of segments can leverage the flatMap(Function<Segment, Publisher<T>>) operator to process a single segment into zero, one, or many resulting items, depending on how the result should be processed.

Consider the following example. The function only processes row segments by copying values into a Map:

result.flatMap(segment -> {

    if (!(data instanceof Result.RowSegment)) {
        return Mono.empty();
    }

    Result.RowSegment data = (Result.RowSegment) segment;

    Map<String, Object> rowData = new HashMap<>();
    for (ColumnMetadata column : data.row().getMetadata().getColumnMetadatas()) {
        rowData.put(column.getName(), data.row().get(column.getName()));
    }

    return Mono.just(rowData);
})

To avoid repetative patterns of instanceof checks, results can be filtered regarding their segments that a Result should hold. filter(Predicate<Segment> filter) returns a filtered Result. That is useful when interested only in particular segments. The code above could be rewritten to:

result.filter(Result.RowSegment.class::isInstance).flatMap(segment -> {

    Result.RowSegment data = (Result.RowSegment) segment;

    Map<String, Object> rowData = new HashMap<>();
    for (ColumnMetadata column : data.row().getMetadata().getColumnMetadatas()) {
        rowData.put(column.getName(), data.row().get(column.getName()));
    }

    return Mono.just(rowData);
});

A segment type that was introduced with this release is the message segment. Messages are of informational, warning or error nature and can lead to error signals by translating these into R2dbcException.

The segment API now gives access to SQL warnings that weren’t accessible in the previous R2DBC release.

result.filter(Result.Message.class::isInstance).flatMap(data -> {

    Result.Message message = (Result.Message) data;
    assertThat(message.errorCode()).isZero();
    assertThat(message.sqlState()).isEqualTo("S0000");
    assertThat(message.message()).isEqualTo("error message desc");
    assertThat(message.exception()).isInstanceOf(R2dbcNonTransientResourceException.class);

    return Mono.just(data);
}))

The filter(…) operator can also be used to filter out message segments so you can create a Result that doesn’t contain any segments leading to an error:

result.filter(it -> !(it instanceof Result.Message)).map(…)

Subsequent operators (map, getRowsUpdated, flatMap) process the result in its filtered form. To illustrate this a bit more, the following code would filter out all update counts and consuming the update count through getRowsUpdated would never return the actual result:

result.filter(it -> !(it instanceof Result.UpdateCount)).getRowsUpdated()

The segments API is an advanced mechanism to consume results and segments are only valid within the map/flatMap operator function. Segments must never leave these functions as they are invalidated once the function call terminates.

You can find the full list of API changes in the R2DBC 0.9.0.M2 announcement blog post.

This release ships a first batch of drivers that implement the specification changes. Watch out for future evolution or reach out to the maintainers of the driver you’re interested in if the driver doesn’t fully support the specification yet.

Second Milestone of R2DBC SPI 0.9 Released

Fri, 09 Jul 2021 15:28:00 +0000

Dear R2DBC Community,

We are thrilled to announce the second first milestone of the R2DBC 0.9 specification (0.9.0.M2) that ships several changes. One of them is a long-awaited feature to consume out parameters from stored procedures. Here’s a short summary of the changes:

Consumption of OUT Parameters by introducing OutParameters. Row and OutParameters now share the common superinterface Readable.
Introduction of the Result.map(Function<Readable, T>) method.
Introduction of the Result.Segment API type hierarchy and Result.filter(Predicate<Segment>) and Result.flatMap(Function<Segment, Publisher<T>>) methods to consume arbitrary statement results.
Lifecycle support by introducing the Lifecycle interface.
Removal of generic type of ConnectionFactoryOptions.getValue(Option) and getRequiredValue(…).
Deprecate RowMetadata.getColumnNames() and introduce RowMetadata.contains(String) to simplify constraints and usage around column presence checks.
Support for Lock Wait and Statement Timeouts through Connection.setLockWaitTimeout(Duration) and Connection.setStatementTimeout(Duration) methods.

This release provides a stable revision of the specification for R2DBC implementors. We expect drivers and implementations to adopt these changes within the next weeks so that we can expect implementations to be available during August where we plan to finish the milestone release train with the bill of materials.

Mailing list: https://groups.google.com/g/r2dbc
Changelog: https://r2dbc.io/spec/0.9.0.M2/CHANGELOG.txt
Specification document: https://r2dbc.io/spec/0.9.0.M2/spec/html/
Javadoc: https://r2dbc.io/spec/0.9.0.M2/api/

R2DBC Proxy Tips: Observability

Wed, 02 Jun 2021 01:00:00 +0000

This is the third post of the “R2DBC Proxy Tips” mini blog series.

This post shows how to achieve observability - metrics and distributed tracing.

To implement observability, we need to capture the interactions with the R2DBC objects. ProxyMethodExecutionListener is suitable for this use case. This listener is an extension of ProxyExecutionListener and provides callbacks for all the methods defined in the R2DBC SPI classes.

For example, the beforeCreateOnConnectionFactory method is called back before the create method on ConnectionFactory. The afterExecuteOnStatement is invoked after the execute method on Statement.

By using these callback methods, you can easily add logic to populate metrics, start a new span, or take any action you want.

For example, the following listener populates metrics for the time taken to obtain a connection:

public class MyMetricsListener implements ProxyMethodExecutionListener {

	private MeterRegistry registry;

	public MyMetricsListener(MeterRegistry registry) {
		this.registry = registry;
	}

	@Override
	public void beforeCreateOnConnectionFactory(MethodExecutionInfo methodExecInfo) {
		Timer.Sample sample = Timer.start(this.registry);
		methodExecInfo.getValueStore().put("connectionCreate", sample);
	}

	@Override
	public void afterCreateOnConnectionFactory(MethodExecutionInfo methodExecInfo) {
		Timer.Sample sample = methodExecInfo.getValueStore()
				.get("connectionCreate", Timer.Sample.class);

		Timer timer = Timer
				.builder("r2dbc.connection")
				.description("Time to create(acquire) a connection")
				.tags("event", "create")
				.register(this.registry);

		sample.stop(timer);
	}

}

As mentioned in the second post, we use the ValueStore API to pass the sample object between methods.

MetricsExecutionListener and QueryTimeMetricsExecutionListener are other sample metrics listener implementations.

For distributed tracing, the implementation is similar to the above sample code for metrics. You can create spans at method invocations, pass them to ValueStore, and finish them in the appropriate method invocations.

This TracingExecutionListener example shows how to create spans by using the zipkin Tracer.

For Spring Cloud Sleuth users, we have good news. This commit enables out of the box support for R2DBC instrumentation.

R2DBC Proxy Tips: Share values in callbacks with ValueStore

Wed, 05 May 2021 01:00:00 +0000

R2DBC Proxy is a framework that provides callbacks to the R2DBC interactions. It consists of a thin layer on top of the R2DBC drivers to implement cross-cutting concerns, such as query loggings, observability instrumentation, or your own actions.

R2DBC Proxy Tips is a series of mini blog posts. I will introduce typical usage of the R2DBC proxy and sample implementations with tips.

This is the second post of the “R2DBC Proxy Tips” mini blog series.

This post shows how to pass values across proxy callbacks.

When you implement a ProxyExecutionListener, you may want to pass values from the beforeQuery to the afterQuery callback, pass values from the beforeMethod to the afterMethod callback, or bind to Connection scope and share across multiple callbacks.

In imperative programming, ThreadLocal provides the functionality to pass values between methods or keep values bound to a database connection. However, in reactive, ThreadLocal is not a reliable place to store values.

To address this, R2DBC Proxy provides ValueStore. This provides a Map-like API to put and get objects by key. ValueStore is available for the following scopes:

Between beforeMethod and afterMethod through MethodExecutionInfo
Between beforeQuery and afterQuery through QueryExecutionInfo
Connection bound through ConnectionInfo
Statement bound through StatementInfo for the bind parameter converter

The following hypothetical usage shows how to put or get values to or from Connection and method-bound ValueStore instances.

static class MyFilter implements ProxyMethodExecutionListener {

  private static final Logger log = LoggerFactory.getLogger(MyFilter.class);

  private final Clock clock;

  public MyFilter(Clock clock) {
    this.clock = clock;
  }

  @Override
  public void afterCreateOnConnectionFactory(MethodExecutionInfo methodInfo) {
    // connection scoped store
    ValueStore store = methodInfo.getConnectionInfo().getValueStore();
    store.put("conn-created", this.clock.instant());
  }

  @Override
  public void beforeExecuteOnStatement(MethodExecutionInfo methodInfo) {
    // method scoped store
    ValueStore store = methodInfo.getValueStore();
    store.put("stmt-before", this.clock.instant());
  }

  @Override
  public void afterExecuteOnStatement(MethodExecutionInfo methodInfo) {
    ValueStore connectionStore = methodInfo.getConnectionInfo().getValueStore();
    ValueStore methodStore = methodInfo.getValueStore();

    Instant connCreated = connectionStore.get("conn-created", Instant.class);
    Instant stmtBefore = methodStore.get("stmt-before", Instant.class);

    Instant now = this.clock.instant();
    Duration connToNow = Duration.between(connCreated, now);
    Duration stmtToNow = Duration.between(stmtBefore, now);

    log.info("From connection created={}", connToNow);
    log.info("From statement executed={}", stmtToNow);
  }

}

The next blog post will show how to implement a listener for metrics and distributed tracing.

The ValueStore is used to keep the current metrics and span information.

R2DBC Proxy Tips: Query Logging

Wed, 14 Apr 2021 01:00:00 +0000

R2DBC Proxy Tips is a series of mini blog posts. I will introduce typical usage of the R2DBC proxy and sample implementations with tips.

This first post explains the prime use case of the R2DBC Proxy: “how to log queries”.

Implementation

In R2DBC Proxy, a callback is implemented as ProxyExecutionListener.

This listener interface defines beforeQuery and afterQuery callback methods. As the names suggest, they are invoked when queries get executed.

To log the executed queries, you can create a listener that performs logging in beforeQuery or afterQuery. (Note, some of the values, such as the time the query took to run, are available only on the afterQuery.)

The following example shows a listener implementation that logs queries after each query:

public class LoggingListener implements ProxyExecutionListener {

  private static final Logger logger = LoggerFactory.getLogger(LoggingListener.class);

  private final QueryExecutionInfoFormatter formatter = QueryExecutionInfoFormatter.showAll();

  @Override
  public void afterQuery(QueryExecutionInfo execInfo) {
    logger.info(this.formatter.format(execInfo));
  }

}

Instead of creating a dedicated LoggingListener class, you can also register a listener for this purpose while creating a proxy ConnectionFactory.

QueryExecutionInfoFormatter formatter = QueryExecutionInfoFormatter.showAll();

ConnectionFactory original = ...;

// create a proxy ConnectionFactory
ConnectionFactory connectionFactory = ProxyConnectionFactory.builder(original)
    .onAfterQuery(queryInfo -> {  // listener
        logger.info(formatter.format(queryInfo));
    })
    .build();

Sample Output (multiline for display purpose)

Thread:http-nio-8080-exec-3(38) Connection:3 Transaction:{Create:1 Rollback:0 Commit:0}
Success:True Time:5 Type:Statement BatchSize:0 BindingsSize:1
Query:["INSERT INTO test VALUES ($1)"] Bindings:[($1=100)]

Customizing a Formatter

QueryExecutionInfoFormatter is a utility class that converts QueryExecutionInfo to a String for logging. The default static method, showAll(), creates a formatter that converts all information available in the query execution.

However, it may be too long for your logging or you may want to customize the format.

QueryExecutionInfoFormatter provides show... methods to selectively choose the information you want to include, or you can use addConsumer to add your own conversion logic. The following example uses showQuery() and showBinding() with new lines for nicer formatting:

QueryExecutionInfoFormatter custom = new QueryExecutionInfoFormatter()
    .addConsumer((info, sb) -> {
      // custom conversion
      sb.append("ConnID=");
      sb.append(info.getConnectionInfo().getConnectionId());
    })
    .newLine()
    .showQuery()
    .newLine()
    .showBindings()
    .newLine();

Sample output:

ConnID=1
Query:["SELECT * FROM employee WHERE id=$1"]
Bindings:[($1=200)]