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/1.

Далі, використання 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 не потрібен додатковий етап обробки коду — трансляція, то процес компіляції в цьому випадку буде швидшим.

В наступних прикладах порівнюється синтаксис SQLJ з використанням JDBC.

PreparedStatement stmt = conn.prepareStatement(
   "SELECT LASTNAME"
 + " , FIRSTNME"
 + " , SALARY"
 + " FROM DSN8710.EMP"
 + " WHERE SALARY BETWEEN ? AND ?");
stmt.setBigDecimal(1, min);
stmt.setBigDecimal(2, max);
ResultSet rs = stmt.executeQuery();
while (rs.next()) {
  lastname = rs.getString(1);
  firstname = rs.getString(2);
  salary = rs.getBigDecimal(3);
  // Print row...
}
rs.close();
stmt.close();

#sql private static iterator EmployeeIterator(
                   String, String, BigDecimal);
...
EmployeeIterator iter;
#sql [ctx] iter = {
  SELECT LASTNAME
       , FIRSTNME
       , SALARY
    FROM DSN8710.EMP
   WHERE SALARY BETWEEN :min AND :max
};
do {
  #sql {
    FETCH :iter
     INTO :lastname, :firstname, :salary
  };
  // Print row...
} while (!iter.endFetch());
iter.close();

PreparedStatement stmt = conn.prepareStatement(
    "SELECT MAX(SALARY), AVG(SALARY)"
  + " FROM DSN8710.EMP");
rs = stmt.executeQuery();
if (!rs.next()) {
  // Error—no rows found
}
maxSalary = rs.getBigDecimal(1);
avgSalary = rs.getBigDecimal(2);
if (rs.next()) {
  // Error—more than one row found
}
rs.close();
stmt.close();

#sql [ctx] {
  SELECT MAX(SALARY), AVG(SALARY)
    INTO :maxSalary, :avgSalary
    FROM DSN8710.EMP
};

stmt = conn.prepareStatement(
   "INSERT INTO DSN8710.EMP (" +
"EMPNO, FIRSTNME, MIDINIT, LASTNAME, HIREDATE, SALARY"
 + ") VALUES (?, ?, ?, ?, CURRENT DATE, ?)");
stmt.setString(1, empno);
stmt.setString(2, firstname);
stmt.setString(3, midinit);
stmt.setString(4, lastname);
stmt.setBigDecimal(5, salary);
stmt.executeUpdate();
stmt.close();

#sql [ctx] {
  INSERT INTO DSN8710.EMP
    (EMPNO, FIRSTNME, MIDINIT, LASTNAME, HIREDATE, SALARY)
  VALUES
    (:empno, :firstname, :midinit, 
    :lastname, CURRENT DATE, :salary)
};

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

• http://sqlj.org/
• IBM Redbook: DB2 for z/OS and OS/390: Ready for Java