针对我的关于Criteria查询的帖子，有许多评论。我最终得以回应。许多人建议一种更面向树的方案，其中我们将所有逻辑运算符视为二元运算符。例如，匿名者提出了以下建议
session.createCriteria( Project.class,
or(
eq("name", "Hibernate"),
like("description", "%ORM%")
)
);
当然，逻辑运算符是二元的。但它们也是/结合的/，这似乎被树方法所否定。我们永远不会这样写
( (x=2 and x=1) and y=3 ) and z=4
我们总是这样写
x=2 and x=1 and y=3 and z=4
这在Criteria查询的情况下尤其相关，因为常见的情况是我们使用合取组合许多条件。（有人对我的“合取”和“析取”的使用提出异议，但我不知道还有什么其他词可以用来表示用“与”/“或”组合的表达式串。）
实际上，当前的API已经允许这种替代方案。我们有了Expression.or()和Expression.and()。但对我来说，它们似乎比add()更混乱。
Carl Rosenberger，SODA和db4o的幕后人物，写道
In my opinion a clean object querying system is the first and foremost basis for any standard on object persistence. Enhancers/Reflection/BCEL/code calls to make objects persistent all this can be very quickly exchanged, if you want to switch the underlying system. Queries can not be exchanged!
我完全同意！这是完全正确的。他继续说
Could you maybe bring this thought into JDO 2.0 ? Please ? Besides, I am positive that a de-facto standard for object querying will have a much greater impact on the industry than JDO. Java is not the only programming language on this planet.
事实上，我曾向专家小组的几位成员提到过采用更好的查询方法的想法，但得到的积极回应不多。此外，我并不完全相信在委员会环境中设计一个漂亮的查询语言或API是可能的。这类事情需要一个强有力的统一愿景。委员会在标准化成熟解决方案以解决已充分理解的问题方面做得很好，但我认为面向对象的查询是一个远未充分理解的问题。特别是，似乎并不普遍认为面向ORM的查询语言会与面向对象数据库的查询语言截然不同！
James Strachan 在推广 Groovy，他新的与 JVM 兼容的语言（我不确定是否完全正确地称其为脚本语言），它看起来很像是 Python，但具有 SmallTalk 中最好的一项特性：闭包。（题外话：似乎普遍认为 JDK 集合 API 是 Java 的一个优点。但如果你曾经在小 Talk 中使用过集合，你就会知道 Java 在处理集合方面的实际贫困。迭代器远比具有闭包的语言中可用的更函数式的方法丑陋得多。如果有什么我想在 Java 中改进的，那不是泛型、枚举等的缺乏，而是闭包的缺乏。）无论如何，我对 James 要说的话很感兴趣，但我对将面向对象的表达式语言作为 ORM 查询语言的起点持怀疑态度。首先，关系数据库实现与面向对象语言非常不同的空值语义。事实上，SQL 的三元逻辑与编程语言实现的二进制逻辑大不相同。其次，在面向对象的世界中，等价性是一个比数据库世界更难以捉摸的概念。基于这些原因以及其他原因，我们选择基于 SQL 而不是类似 Java 的语法来构建 HQL。我认为这是我们做出的最好的决定之一。
Razvan 描述了他称之为“关联查询模型”（类似于 JavaSpaces 中的查询）。如果我没有弄错，这通常被称为“按示例查询”。我会在未来的文章中讨论 Hibernate 的新 Example 查询 API...
