java - Hibernate 嵌套属性标准

Question

让我们假设，每首歌都属于一张专辑，该专辑由居住在同一个国家的一位艺术家创作。像这样的查询

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

失败，可以使用 createAlias 或 createCriteria (如 here )修复，以便执行所需的连接。我正在这样做并且它有效，但我缺少一些背景:

为什么会这样工作？假设没有嵌入属性，加入是唯一的选择，不是吗？

关于连接类型，没有任何歧义:它必须是 INNER JOIN，否则相等性无法成立，对吗？

Answer 1

关于为什么某些东西是这样构建的问题总是很棘手，您可能需要直接询问作者。

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

无论如何，您编写的查询比 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 也更具可读性)，但我认为这就是Criteria 背后的基本思想:更安全、更可重用的查询部分。