SQLJ

На момент появления консорциума JSQL (впоследствии ставшего одноимённым с разрабатываемым им стандартом) в 1997 году идея о взаимодействии реляционных СУБД и программ на Java была не нова. Компанией JavaSoft (дочерним подразделением компании Sun) уже был разработан интерфейс JDBC (англ. Java DataBase Connectivity — «соединение с БД средствами Java»), включённый в стандарт языка, начиная с момента выпуска JDK 1.1. Однако в силу определённых причин (см. «SQLJ и JDBC») возможностей, предоставляемых этим интерфейсом было недостаточно.

Спецификация стандарта SQLJ состоит из трех частей:

• Уровень 0 регламентирует встраивание SQL-операторов в текст программы на Java;
• Уровень 1 определяет обратное включение, а именно, реализацию в использующих SQL СУБД хранимых процедур и функций на языке Java;
• Уровень 2 устанавливает соответствие между типами данных.

К концу 1998 года все три уровня спецификации были завершены и представлены для рассмотрения в ANSI в качестве дополнений к стандарту SQL. Первые две части нового стандарта были включены соответственно в части SQL/OLB и SQL/PSM стандарта SQL:1999; третья часть вошла как отдельный модуль SQL/JRT в стандарт SQL:2003

Обычно применительно к разработке приложений, работающих с БД, под SQLJ обычно понимается именно уровень 0.

Приведем простой пример Java-класса, использующего SQLJ для получения результатов запроса из Oracle.

import java.sql.*;
import oracle.sqlj.runtime.Oracle;
public class SingleRowQuery extends Base {
   public static void main(String[] args) {
      try {
         connect();
         singleRowQuery(1);
      } catch (SQLException e) {
         e.printStackTrace();
      }
   }
   public static void singleRowQuery(int id) throws SQLException {
      String fullname = null;
      String street = null;
      #sql {
         SELECT fullname,
            street INTO :OUT fullname,
            :OUT street FROM customer WHERE ID = :IN id};
      System.out.println("Customer with ID = " + id);
      System.out.println();
      System.out.println(fullname + " " + street);
   }
}

Из рассмотрения приведённого кода ясно, что в сам текст процедуры singleRowQuery встраивается SQL-запрос, и встраивание это организовано по определённым правилам:

• Текст запроса находится внутри директивы #sql {...};
• Переменные, внешние по отношению к SQL-запросу, задаются внутри него в определенном формате

Подробно все синтаксические конструкции будут рассмотрены далее.

Логично возникновение вопроса о причинах создания двух параллельных стандартов для реализации технологий доступа к СУБД.

Для начала стоит отметить, что SQLJ и JDBC относятся к разным семействам стандартов и концептуально они разные. JDBC является API, входящим в стандарт языка Java и ориентированным на передачу сформированной программой SQL-конструкции в БД, а также обработку результата. SQLJ же является подмножеством стандарта SQL SQL/OLB — для него первичным является понятие базы данных, а язык, в который включаются SQL-конструкции, вторичен. Согласно этому стандарту встраивание SQL-операторов допускается не только в Java, но и в языки программирования Ada, C, COBOL, Fortran, MUMPS, PL/I.

Далее, использование SQLJ на самом деле неявно подразумевает вызов JDBC-методов, так как в данном случае они выполняют роль соответственно высоко- и низкоуровневого API. Если углубиться в подробности реализации технологий SQLJ и JDBC, то можно обнаружить, что любые SQLJ-директивы прозрачно для программиста специальной подсистемой, называемой SQLJ-препроцессором, транслируются в JDBC-вызовы. Благодаря этому можно спокойно сочетать в одном фрагменте кода SQLJ- и JDBC-вызовы, при необходимости используя общий контекст.

На самом деле, в каждом конкретном случае, когда требуется выполнение SQL-оператора, выбор между SQLJ и JDBC стоит делать, исходя из характера предполагаемой операции. Если это сложный поисковый запрос с возможными вариациями по количеству условий на поиск — тогда однозначно более целесообразно будет формирование текстовой строки запроса и последующее его выполнение через JDBC; если же требуется просто подстановка каких-то переменных либо вычислимых выражений — тогда эргономичнее в части длины кода будет написать SQLJ-директиву.

Для того, чтобы эффективно использовать синтаксические новшества, вносимые стандартом SQLJ, необходимо предварительно разобраться в их особенностях, связанных с процессом разбора SQLJ-конструкций.

Любые SQLJ-конструкции начинаются с директивы #sql, в частности, блоки, содержащие внутри себя собственно SQL-запросы, задаются как #sql {…}.

int i, j;
i = 1;
#sql {	SELECT field INTO :OUT j
            FROM table
            WHERE id = :IN i };
System.out.println(j);

int i = 1;
#sql {	SELECT result
	    FROM  table1
	    WHERE field1 = :(x[i++]) AND field2 = :(y[i++]) AND field3 = :(z[i++]) };
System.out.println(i);

SELECT result
    FROM    table1
    WHERE   field1 = :(x[1]) AND field2 = :(y[1]) AND field3 = :(z[1])

SELECT result
    FROM    table1
    WHERE   field1 = :(x[1]) AND field2 = :(y[2]) AND field3 = :(z[3])

CREATE TABLE people (
	fullname VARCHAR(50),
	birthyear NUMERIC(4,0))

ByPos positer;
String name = null;
int year = 0;
#sql positer = {SELECT fullname, birthyear FROM people};
for(;;)
{
	#sql {FETCH :positer INTO :name, :year};
	if (positer.endFetch())
		break;
	System.out.println(name + " was born in " + year);
		
}

#sql public iterator ByName (
	String fullNAME,
	int birthYEAR);

ByName namiter;
#sql namiter = {SELECT fullname, birthyear FROM people};
String s;
int i;
while (namiter.next())
{
	i = namiter.birthYEAR();
	s = namiter.fullNAME();
	System.out.println(s + " was born in "+i);
}

#sql {CALL proc (:myarg)};

int i;
#sql i = {VALUES(func(34))};

Так как SQLJ-директивы при своём использовании используют JDBC-вызовы, то представляет интерес возможность использовать эти технологии совместно. Достаточно легко преобразовывать итераторы в объекты ResultSet и наоборот.

Преобразование объекта ResultSet осуществляется очень просто. Для этого сначала нужно определить итератор с именованием столбцов (в нашем примере он будет обозначаться Employees, а затем выполнить операцию CAST:

#sql iterator Employees (String ename, double sal);

PreparedStatement stmt = conn.prepareStatement();
String query = "SELECT ename, sal FROM emp WHERE ";
query += whereClause;
ResultSet rs = stmt.executeQuery(query);
Employees emps;
#sql emps = {CAST :rs};
while (emps.next()) {
      System.out.println(emps.ename() + " earns " + emps.sal());
}
emps.close();
stmt.close();

Отдельно стоит обратить внимание, что после привязки результата запроса к итератору отдельно закрывать результат запроса нет надобности — это за программиста сделает сам препроцессор.

Обратный процесс — преобразование итератора в объект ResultSet производится с помощью итераторов особого типа, так называемых слабо типизированных (англ. weakly typed) итераторов.

sqlj.runtime.ResultSetIterator iter;
#sql iter = {SELECT ename FROM emp};

ResultSet rs = iter.getResultSet();
while (rs.next()) {
      System.out.println("employee name: " + rs.getString(1));
}
iter.close();

В этом случае связь между итератором и результатом запроса также сохраняется и закрывать следует именно итератор.

Как уже упоминалось ранее, сравнивать SQLJ как технологию проще всего с аналогичной Java-ориентированной технологией того же назначения, а именно — с JDBC. Ситуация усложняется тем, что эти технологии не параллельны и не вполне взаимозаменяемы, а находятся друг над другом архитектурно.

1. Запрос одинакового назначения, записанный в JDBC-вызовах и в SQLJ-директиве, в большинстве случаев будет более компактно записан в тексте программы именно во втором случае, что уменьшает размер листинга и вероятность ошибки, связанной со сборкой итоговой строки запроса из небольших фрагментов;
2. Любая SQLJ-директива на этапе компиляции разбирается и проверяется препроцессором, следовательно, все ошибки синтаксиса выявляются ещё на этом этапе, в отличие от JDBC, где контролируется правильность конструкций только с точки зрения синтаксиса Java — за разбор и правильность собственно запроса отвечает уже СУБД, что, естественно, приводит к тому, что ошибки такого рода будут выявлены уже на этапе запуска;
3. Собственно сам препроцессор (обычно имеющий название sqlj) не входит в JDK; он и необходимые для его работы библиотеки обычно предоставляются производителем СУБД. Это закономерно — как показано выше, SQLJ гораздо более близок к СУБД, чем собственно к языку Java; более того, препроцессор должен учитывать особенности SQL-синтаксиса «своей» СУБД;
4. В большинстве случаев — особенно это касается часто выполняющихся сложных запросов, работающих с большими массивами данных, — SQLJ-директива будет выполняться в среднем быстрее аналогичного набора JDBC-вызовов. Это связано с тем, что план для соответствующего запроса в случае SQLJ-директивы будет строиться только один раз, а затем использоваться повторно, в отличие от JDBC, где построение плана будет осуществляться при каждом вызове;
5. Создаваемый при трансляции SQLJ-директивы план запроса при необходимости может быть подвергнут настройке со стороны пользователя; в случае JDBC такая возможность по понятным причинам отсутствует;
6. Если запрос требует значительных изменений в каждом конкретном случае (простой пример: поисковый запрос по набору полей, значения в части которых могут отсутствовать), то проще использовать JDBC, так как преимуществ в использовании SQLJ здесь нет;
7. Так как при использовании JDBC нет надобности в дополнительном этапе обработки кода — трансляции, то процесс компиляции в этом случае будет быстрее.

1. SQLJ требует дополнительного шага препроцессирования.
2. Большинство IDE не имеют поддержки SQLJ.
3. SQLJ не имеет поддержки в большинстве ORM-фреймворков, таких как Hibernate.

1. Эндрю Эйзенберг, Джим Мелтон. Связывания для объектных языков (неопр.) (недоступная ссылка). Дата обращения: 12 ноября 2008. Архивировано 17 сентября 2011 года.
2. Эндрю Эйзенберг, Джим Мелтон. SQLJ – Часть 1 (неопр.) (недоступная ссылка). Дата обращения: 12 ноября 2008. Архивировано 13 февраля 2009 года.
3. IBM Redbooks. DB2 for z/OS and OS/390: Ready for Java (неопр.) (недоступная ссылка). Дата обращения: 12 ноября 2008. Архивировано 25 августа 2011 года.
4. Oracle Database 11g. SQLJ Developer's Guide and Reference (неопр.) (недоступная ссылка). Дата обращения: 12 ноября 2008. Архивировано 25 августа 2011 года.