Overriding the SQL statements in applications that use inline methods

If you are using inline methods in an application, you can replace, at run time, the SQL statements in those methods with similar SQL statements.

When you call the DataFactory.getData() method to create an implementation of the Data interface, you can pass a java.util.Map<Object,Object> object. The keys in the Map are the SQL statements that you want to replace. The values in the Map are the SQL statements that you want to use instead.

When you call methods in the Data object that have a String sql parameter, pureQuery tries to match each SQL statement that you pass to those methods with keys in the Map object. Whenever there is a match for an SQL statement that is used as a key, pureQuery uses the SQL statement that is used as the corresponding value in the Map. If there is no match, then pureQuery runs the original SQL statement.

Restrictions

SQL statements that are passed to methods must exactly match the SQL statements that are used as keys. For example, if the spacing or the capitalization differs, two otherwise identical SQL statements do not match.

An SQL value must be similar enough to the SQL key to run properly when a Data method is invoked. For example, an INSERT statement cannot replace a SELECT statement.

An SQL key and value must have compatible inputs and outputs. For example, an SQL SELECT statement that returns Automobile objects cannot replace a SELECT statement that returns the properties of Airplane objects.

Examples

A simple example is replacing the SQL statements used in a Production system with those that were tested in a Test system. However, overriding SQL statements can be useful in more complicated situations.

Suppose that you need to run SQL statements that manipulate various amounts of data. For example, you might need business reports that summarize data by day, week, or quarter. Or you might want to restrict the queries that employees issue by their levels of security access. In such situations, the difference between one run of the application and another are due to variations in the SQL performed.

Before pureQuery, solutions for this sort of problem included options like these:

Such approaches do work. However, pureQuery lets you create a single application that can access an instance of a Map that is perhaps serialized to a file, or otherwise accessible to a running application. The choice of Map object decides what the application does.

When you do not provide a Map, your application can run the basic, default, low-impact, high-security versions of the SQL statements. When you do provide a Map, it can contain SQL statements that provide the appropriate levels of access to the user running the application.


Feedback