Изучаем Java EE 7 - [99]

Листинг 6.28. Типобезопасный запрос с использованием критериев, обеспечивающий выборку всех клиентов старше 40 лет

CriteriaBuilder builder = em.getCriteriaBuilder();
CriteriaQuery criteriaQuery = builder.createQuery(Customer.class);
Root c = criteriaQuery.from(Customer.class);
criteriaQuery.select(c). where(builder.greaterThan(c.get(Customer_.age), 40));
Query query = em.createQuery(criteriaQuery). getResultList();
List customers = query.getResultList();

Опять-таки это лишь примеры того, что вы можете сделать с помощью Criteria API. Это очень богатый API-интерфейс, который всесторонне охарактеризован в главах 5 и 6 спецификации JPA 2.1.

Примечание

Классы, используемые в случае со статической метамоделью, например Attribute или SingularAttribute, являются стандартными и определены в пакете javax.persistence.metamodel. Однако генерирование классов статической метамодели зависит от реализации. EclipseLink использует внутренний класс CanonicalModelProcessor. Этот класс может вызываться вашей интегрированной средой разработки, пока вы разрабатываете Java-команду, Ant-задание или Maven-плагин.

«Родные» запросы

JPQL обладает очень богатым синтаксисом, который позволяет обрабатывать сущности в любой форме и обеспечивает переносимость между базами данных. JPA дает возможность использовать специфические особенности баз данных благодаря «родным» запросам. «Родные» запросы принимают «родной» SQL-оператор (SELECT, UPDATE или DELETE) в качестве параметра и возвращают экземпляр Query для выполнения этого оператора. Однако нельзя рассчитывать на переносимость «родных» запросов между базами данных.

Если код не является переносимым, то почему бы не использовать JDBC-вызовы? Главная причина, в силу которой следует задействовать «родные» запросы JPA, состоит в том, что результат запроса будет автоматически преобразован обратно в сущности. Если вы захотите извлечь все экземпляры сущности Customer из базы данных с использованием SQL, то вам потребуется прибегнуть к методу EntityManager.createNativeQuery(), принимающему в качестве параметров SQL-запрос и класс-сущность, в который должен быть отображен результат.

Query query = em.createNativeQuery("SELECT * FROM t_customer", Customer.class);
List customers = query.getResultList();

Как вы можете видеть в приведенном фрагменте кода, SQL-запрос является строкой, которая динамически генерируется во время выполнения (точно так же, как динамические JPQL-запросы). Опять-таки запрос может быть комплексным, и, поскольку поставщик не будет заранее знать о нем, он станет каждый раз интерпретировать его. Подобно именованным запросам, «родные» могут задействовать аннотации для определения статических SQL-запросов. Именованные «родные» запросы определяются с помощью аннотации @NamedNativeQuery, которую необходимо поместить в код любой сущности (см. код ниже). Как и в случае с именованными JPQL-запросами, имя запроса должно быть уникальным в единице сохраняемости.

@Entity
@NamedNativeQuery(name = "findAll", query="select * from t_customer")
@Table(name = "t_customer")
public class Customer {…}

Запросы к хранимым процедурам

До сих пор у всех разных запросов (JPQL или SQL) было одно и то же назначение: отправка запроса от вашего приложения к базе данных, которая выполнит его и отошлет назад результат. Хранимые процедуры отличаются в том смысле, что они фактически хранятся в самой базе данных и выполняются в ее рамках.

Хранимая процедура — это подпрограмма, имеющаяся в распоряжении приложений, которые осуществляют доступ к реляционной базе данных. Хранимые процедуры обычно используются для экстенсивной или комплексной обработки, которая требует выполнения нескольких SQL-операторов либо для решения повторяющихся задач, связанных с работой с большими объемами данных. Как правило, хранимые процедуры пишутся на том или ином языке, близком к SQL, и, следовательно, не являются легко переносимыми между базами данных от разных поставщиков. Однако сохранение кода в базе данных даже в непереносимой форме обеспечивает многие преимущества.

• Лучшую производительность благодаря предварительной компиляции хранимой процедуры, а также повторного использования плана ее выполнения.

• Сохранение статистики, касающейся кода, для поддержания его оптимизированным.

• Снижение количества данных, передаваемых по сети, благодаря сохранению кода на сервере.

• Изменение кода в центральной локации без репликации в нескольких разных программах.

• Хранимые процедуры, которые могут использоваться множеством программ, написанных на разных языках (а не только на Java).

• Скрытие необработанных данных путем предоставления доступа к информации только хранимым процедурам.

• Усиление мер безопасности путем предоставления пользователем разрешения на выполнение той или иной хранимой процедуры независимо от разрешений, связанных с базовой таблицей.

Взглянем на пример из практики — архивирование старых книг и компакт-дисков. После определенной даты книги и компакт-диски должны помещаться в архив на конкретном складе, а это означает, что затем их придется физически перевозить со склада к перекупщику. Архивирование книг и компакт-дисков может отнимать много времени, поскольку потребуется обновлять несколько таблиц (с именами, например, T_Inventory, T_Warehouse, T_Book, T_CD, T_Transport и т. д.). Таким образом, мы можем написать хранимую процедуру для перегруппировки нескольких SQL-операторов и повышения производительности. Хранимая процедура sp_archive_books, определенная в листинге 6.29, принимает archiveDate и warehouseCode в качестве параметров и обновляет таблицы T_Inventory и T_Transport.