jpa ---排序

ORDER BY 允许你对查询结果进行排序。数据库排序比应用程序更有效。要依据集合的顺序，可以使用ORDER BY 操作符。(更多信息参见第三章Entities Part II中@OrderBy 注释)

这是一个JPQL 查询语句中Order By 操作符的所在位置。

select from [where] [group by] [having] [order by]
Order By 的语法为:

ORDER BY expression [ASC | DESC] {, expression [ASC | DESC]}*下面是一些合法的Order By 实例。

SELECT u FROM User u ORDER BY u

SELECT u FROM User u ORDER BY u.address

SELECT u.username, u.id FROM User u ORDER BY u.username DESC

expression 可以是一个标识符号变量，一个单值关联路径，一个状态字段路径表达式。这些查询语句一一演示了Order By 的这些类型。

你必须注意使用Order By 操作符的一些限制。

当使用一个标识符号变量，一个单值关联字段时，你用来对查询进行排序的项目必须是一个可排序的类型，例如数字类型，字符串，字符类型，或是时间日期。

如果你使用一个状态字段路径表达式，同时它也必须出现在SELECT 语句中。

ASC 表示升序(由小到大)，是默认的排序方式。DESC 表示降序排列(由大到小)，使用时显式在查询的Order By 语句上添加它。排序的优先级是按罗列的字段从左到右的顺序进行。

不难理解，下面的查询是不合法的，因为它对一个字段进行排序但它却不在SELECT 语句中。

SELECT u.username, u.id FROM User u ORDER BY u.password
批量处理(BULK OPERATIONS)
JPQL 提供了一种替代方案，用一条语句更新或删除一个或多个实体。JPQL 中批处理支持一次可以处理一个实体类型(和它的子类)。也就是说，你只能在FROM 或UPDATE 指定唯一实体。这里是一个UPDATE 查询的语法。

UPDATE abstract_persistence_scheama_name [AS] identification_variable
SET state_field | single_value_association_field = value
{,state_field | single_value_association_field = value }*
value 引用必须与你要更新的状态字段或是单值关联字段的类型相同。你可以将下列任意值用于value 。

一个算术表达式

字符串

时间日期(datetime)

布尔值(boolean)

枚举类型(enum)

简单实体表达式

NULL

DELETE 语句看起来如下。

DELETE FROM abstract_persistence_scheama_name [[AS] identification_variable]
[WHERE clause]
WHERE 语句的语法与SELECT 相同(更多信息参见SELECT 语句一节)。DELETE 操作符只影响FROM 语句指定的实体及其子类。此操作不会级联到任何相关的实体。此外，UPDATE 操作符不更新实体的version一列。

批处理操作最终转换成SQL 并在数据库中执行，绕过了持久化环境(persistence context)。当使用一个事务作用域(transaction-scoped)的持久化环境，会在它们所在事务内执行或在一个事务开始时执行。

批量操作和扩展的持久化环境(extended persistence context)的组合在管理上有所不同。因为一个扩展持久化环境不会与数据库同步，直到参与到一个事务中去，你可以有一些实体已经删除了，但仍可能存在于持久化环境中。

持久化实现通常会在执行批处理操作前禁用一些缓存功能。基于不同的实现，部分或全部缓存功能会被禁用。频繁的使用批处理操作会影响应用程序的性能。基于这些原因，你应该在它们自己的事务内或是一个事务开始时执行批处理操作。

实例
当你使用一个UPDATE 或是DELETE 查询时，你一定会用到Query API 提供的方法--executeUpdate() ，来执行更新或是删除操作。如果你使用getResultList() 或getSingleResult() ，持久化实现会抛出一个IllegalStateException 异常。同样，你用executeUpdate() 来执行一个SELECT 查询，持久化实现会抛出一个IllegalStateException 异常。

下面是一些批量更新的例子。

一个论坛帖子数量的两倍。

Query q2 = em.createQuery("UPDATE Forum AS f "
+"SET f.forumPostCount = f.forumPostCount * 2");

q2.executeUpdate();
将所有的Role 实体的dateUpdated 字段设置为当前日期和时间。

Query q = em.createQuery("UPDATE Role AS r " +
"SET r.dateUpdated = CURRENT_TIMESTAMP");

q.executeUpdate();
将布尔字(pruningEnabled) )段值设置为true 。在agoraBB 应用程序中，用EntityListener 类来设置dateUpdated 和updatedByUser 字段。version字段是由持久化实现进行管理。避开这些弯弯角角，当你执行批量操作时，你的查询写成更新字段。还有，要注意的是，executeUpdate 返回实体更新的数目(删除时返回删除的数量)。

// Assume we already fetched the correct User identified by
// the variable adminUser
Query forumUpdate = em.createQuery("UPDATE Forum AS f " +
"SET f.pruningEnabled = TRUE, f.dateUpdated = CURRENT_TIMESTAMP, " +
"f.version = f.version + 1, f.updatedByUser = :user");

forumUpdate.setParameter("user", adminUser);

int entitiesUpdated = forumUpdate.executeUpdate();
你可以将pruningEnabled 的值设置为null ，将其进行重位。如下所示。

Query pruningReset = em.createQuery("UPDATE Forum AS f " +
"SET f.pruningEnabled = NULL");

pruningReset.executeUpdate();
这条查询设置了enum 类型的字段值。你必须使用enum 类的长限定词，因为enum 不是实体，持久化实现不法获得Status的信息,但它可以识别com.sourcebeat.jpa.model.Status 。

Query enumUpdate = em.createQuery("UPDATE Forum AS f " +
"SET f.status = com.sourcebeat.jpa.model.Status.LOCKED " +
"WHERE f.type = com.sourcebeat.jpa.model.FTPType.ANNONUCEMENT");

int enumUpdateCount = enumUpdate.executeUpdate();
这里有几个DELETE 操作的例子。

删除系统中所有无密码的用户(Users )。

Query removeRoles = em.createQuery("DELETE FROM User u " +
"WHERE u.password = NULL");

int rolesRemoved = removeRoles.executeUpdate();
删除没有主题(Topics )的论坛(Forum )。

Query removeForums = em.createQuery("DELETE FROM Forum f " +
"WHERE f.topics IS EMPTY");

int forumsRemoved = removeForums.executeUpdate();
总结(SUMMARY)
JPQL 提供了大量实体查询，分组，排序和总结的功能。包括丰富的关联(join)操作支持和即时读取延迟关联关系(eagerly fetch lazy relationship)的能力。你已经学习所支持的各种函数和表达式，以及SELECT 语句所能提供的各种选项。本章最后探讨了批量处理操作，它具备使用单条查询语句(实际是指UPDATE 或DELETE 语句)影响一个或多个实体的能力。

现在你应该很熟悉了JPQL 所能提供的丰富的功能，利用它，从简单到复杂一步步地创建自己的查询。


本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/Uoooo/archive/2010/01/11/5176940.aspx