Hibernate嵌套属性标准

马塔蒂努斯

假设,每首歌曲完全属于一个专辑,该专辑是由居住在一个国家/地区的一位艺术家创作的。像这样的查询

createCriteria(Song.class)
    .add(Restrictions.eq("album.artist.country.id", 43)); 

失败,可以使用createAliascreateCriteria(如此进行修复,以便执行所需的连接。我正在做并且可以使用,但是我缺少一些背景:

为什么会这样工作?假设没有嵌入的属性,则联接是唯一的选择,不是吗?

关于联接类型,没有任何歧义:它必须是一个INNER JOIN,否则等式不能成立,对吗?

德拉甘·博扎诺维奇(Dragan Bozanovic)

关于为何以某种方式构建事物的问题总是很棘手,您可能需要直接向作者询问。

我找不到任何与此相关的官方文档,但我认为它与基于字符串的查询(HQL)与基于对象的查询(Criteria)有关。

无论如何,您编写的查询要比条件查询更具有HQL,那么为什么不对整个查询使用HQL?

我了解这只是您编写的用于描述该概念的简短示例,并且在更复杂的Criteria查询中使用基于字符串的路径导航联接也可能很方便,但是Criteria的目的是提供更多类型安全的查询和可重用的条件部分,可用于根据影响最终查询外观的各种其他条件,以大块形式构建查询。

例如,假设您为所有实体属性都预定义了常量,以确保在使用基于字符串的查询时不会出现任何错字:

public final class Album_ {
  public static final String artist = "artist";
}

public final class Artist_ {
  public static final String country = "country";
}

有些工具/框架会自动生成这些类。

因此,您可以通过以下方式生成条件:

createCriteria(Song.class)
 .createCriteria(Album_.artist)
 .createCriteria(Artist_.country)
 ...

对于大多数查询而言,上述方法是不必要的开销,并且会使代码的可读性降低恕我直言(我个人认为,即使StringBuilder涉及到HQL / JPQL或类似的代码,HQL / JPQL也会更具可读性),但我认为这是Criteria的基本思想:更安全,可重用的查询部分。

本文收集自互联网,转载请注明来源。

如有侵权,请联系 [email protected] 删除。

编辑于
0

我来说两句

0 条评论
登录 后参与评论

相关文章