Hibernate 嵌套属性条件

Question

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

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

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

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

关于连接类型，没有歧义：它必须是内部连接，否则等式不成立，对吧？

Answer 1

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

我找不到任何关于此的官方文档，但我认为它与基于字符串的查询 (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";
}

有一些工具/框架可以自动生成这些类。

因此，您可以通过以下方式生成 Criteria：

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

对于大多数查询，上述方法是不必要的开销，并且会降低代码的可读性，恕我直言（我个人认为 HQL/JPQL 更具可读性，即使涉及StringBuilder或类似内容），但我认为这是 Criteria 背后的基本思想：更安全和更可重用的查询部分。

Answer 2

关于连接类型，没有歧义：它必须是内部连接，否则等式不成立，对吧？

您应该使用内部联接。

为什么它会这样工作？

因为hibernate会生成，所以你应该放别名。

你有没有想过 Hibernate Native SQL 呢？ 因为会对数据库进行混乱的查询。