JPA 2.0中的动态类型安全查询

JPA 2.0中的动态类型安全查询2011-02-03 IBM Pinaki Poddar自从 JPA 于 2006 年首次被引入之后，它就得到了 Java 开发社区的广泛支持。该规范的下一个主要更新 —— 2.0 版本（JSR 317） —— 将在 2009 年年底完成。JPA 2.0 引入的关键特性之一就是 Criteria API，它为 Java 语言带来了一种独特的能力：开发一种 Java 编译器可以在运行时验证其正确性的查询。Criteria API 还提供一个能够在运行时动态地构建查询的机制。

本文将介绍 Criteria API 和与之密切相关的元模型（metamodel）概念。您将学习如何使用 Criteria API 开发 Java 编译器能够检查其正确性的查询，从而减少运行时错误，这种查询优于传统的基于字符串的 Java Persistence Query Language （JPQL）查询。借助使用数据库函数或匹配模板实例的样例查询，我将演示编程式查询构造机制的强大威力，并将其与使用预定义语法的 JPQL 查询进行对比。本文假设您具备基础的 Java 语言编程知识，并了解常见的 JPA 使用，比如 EntityManagerFactory 或 EntityManager。

JPQL 查询有什么缺陷？

JPA 1.0 引进了 JPQL，这是一种强大的查询语言，它在很大程度上导致了 JPA 的流行。不过，基于字符串并使用有限语法的 JPQL 存在一些限制。要理解 JPQL 的主要限制之一，请查看清单 1 中的简单代码片段，它通过执行 JPQL 查询选择年龄大于 20 岁的 Person 列表：

清单 1. 一个简单（并且错误）的 JPQL 查询

EntityManager em = ...;
String jpql = "select p from Person where p.age > 20";
Query query = em.createQuery（jpql）;
List result = query.getResultList（）;

这个基础的例子显示了 JPA 1.0 中的查询执行模型的以下关键方面：

JPQL 查询被指定为一个 String（第 2 行）。

EntityManager 是构造一个包含给定 JPQL 字符串的可执行查询实例的工厂（第 3 行）。

查询执行的结果包含无类型的 java.util.List 的元素。

但是这个简单的例子有一个验证的错误。该代码能够顺利通过编译，但将在运行时失败，因为该 JPQL 查询字符串的语法有误。清单 1 的第 2 行的正确语法为：

String jpql = "select p from Person p where p.age > 20";

不幸的是，Java 编译器不能发现此类错误。在运行时，该错误将出现在第 3 或第 4 行（具体行数取决于 JPA 提供者是否在查询构造或执行期间根据 JPQL 语法解析 JPQL 字符串）。

类型安全查询如何提供帮助？

Criteria API 的最大优势之一就是禁止构造语法错误的查询。清单 2 使用 CriteriaQuery 接口重新编写了清单 1 中的 JPQL 查询：

清单 2. 编写 CriteriaQuery 的基本步骤

EntityManager em = ...
QueryBuilder qb = em.getQueryBuilder（）;
CriteriaQuery<Person> c = qb.createQuery（Person.class）;
Root<Person> p = c.from（Person.class）;
Predicate condition = qb.gt（p.get（Person_.age）, 20）;
c.where（condition）;
TypedQuery<Person> q = em.createQuery（c）;
List<Person> result = q.getResultList（）;