Introducing QueryBuilder

Programmatically constructing SQL queries is a common but cumbersome task. For example, consider this query that retrieves information about a hypothetical IoT device:

select Device.*, Building.name as buildingName, Site.name as siteName 
from Device 
join Building on buildingID = Building.id
join Site on siteID = Site.id
where Device.id = :deviceID

Written in plain text, as above, the query is fairly easy to read and understand. However, in Java, the same query might be declared as follows:

String sql = "select Device.*, Building.name as buildingName, Site.name as siteName " 
    + "from Device "
    + "join Building on buildingID = Building.id "
    + "join Site on siteID = Site.id "
    + "where Device.id = :deviceID";

Even in this simple example, readability is negatively impacted by the addition of double quotes and string concatenation operators. Care must be taken to ensure that whitespace is properly managed. Longer, more complex, queries become increasingly difficult to write and maintain.

The new QueryBuilder class introduced in HTTP-RPC 7.5 simplifies the task of writing SQL queries in Java. Using QueryBuilder, the preceding example could be rewritten as follows:

String sql = QueryBuilder.select("Device.*", "Building.name as buildingName", "Site.name as siteName")
    .from("Device")
    .join("Building").on("buildingID = Building.id")
    .join("Site").on("siteID = Site.id")
    .where("Device.id = :deviceID").toString();

Because SQL verbs and clauses are represented as Java methods and nouns (tables, columns, and predicates) by strings, this version is much more readable and easier to maintain. It also scales better as query complexity increases.

A complete example using QueryBuilder along with HTTP-RPC’s Parameters and ResultSetAdapter classes is shown below. Parameters is used to prepare SQL statements for execution using named parameter values rather than indexed arguments. ResultSetAdapter provides access to the contents of a result set via the Iterable and Map interfaces, facilitating direct serialization of the result data to JSON:

String sql = QueryBuilder.select("Device.*", "Building.name as buildingName", "Site.name as siteName")
    .from("Device")
    .join("Building").on("buildingID = Building.id")
    .join("Site").on("siteID = Site.id")
    .where("Device.id = :deviceID").toString();

Parameters parameters = Parameters.parse(sql);

try (PreparedStatement statement = connection.prepareStatement(parameters.getSQL())) {
    parameters.apply(statement, mapOf(
        entry("deviceID", deviceID)
    ));

    try (ResultSetAdapter resultSetAdapter = new ResultSetAdapter(statement.executeQuery())) {
        JSONEncoder jsonEncoder = new JSONEncoder();

        jsonEncoder.write(resultSetAdapter, System.out);
    }
}

For more information, see the project README.

Named Parameters in JDBC Queries

2/15/2021 Updated for HTTP-RPC 7.6

Prepared statements are a common way to execute parameterized queries in JDBC. For example, the following SQL might be used to retrieve a list of all users whose first or last name matches a particular character sequence:

SELECT * FROM user 
WHERE first_name LIKE ? or last_name LIKE ?

Parameter values are supplied at runtime via indexed setter methods defined by the PreparedStatement class:

statement.setString(1, pattern);
statement.setString(2, pattern);

This works fine for simple queries, but it becomes increasingly difficult to manage as the number of parameters grows. It is also redundant – although this query only requires a single argument, two parameter values must be supplied.

The Java Persistence API (JPA) provides a more convenient alternative using named parameters. For example, the above query might be written as follows in JPQL:

SELECT u FROM User u 
WHERE u.firstName LIKE :pattern or u.lastName LIKE :pattern

This is more readable and less verbose, as the caller only needs to provide the value of the “pattern” parameter once. It is also more resilient to changes, as the arguments are not dependent on ordinal position. Unfortunately, it requires a JPA-compliant object-relational mapping (ORM) framework such as Hibernate, a dependency that may not be satisfiable in some situations.

The Parameters class provided by the HTTP-RPC framework brings named parameter support to JDBC. The parse() method of this class is used to create a Parameters instance from a JPA-like SQL query; for example:

SELECT * FROM user 
WHERE first_name LIKE :pattern or last_name LIKE :pattern

It takes a string or reader containing the query text as an argument:

Parameters parameters = Parameters.parse(query);

The getSQL() method of the Parameters class returns the processed query in standard JDBC syntax. This value can be used in a call to the connection’s prepareStatement() method:

PreparedStatement statement = connection.prepareStatement(parameters.getSQL());

Argument values are specified via the apply() method, as shown below (mapOf() is a convenience method provided by the framework for declaratively instantiating maps values, similar to Map.of() in Java 9):

parameters.apply(statement, mapOf(
entry("pattern", pattern)
));

Once applied, the query can be executed:

ResultSet resultSet = statement.executeQuery();

Note that the Parameters class is not limited to queries; it can also be used for updates.

A complete example can be found here. It is a simple REST service that allows a caller to search a database of pets by owner name.

See the project README for more information.