Question

让我们假设，每首歌都属于一个专辑，该专辑恰好由一位居住在一个国家的艺术家创作。像

这样的查询

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

失败，可以使用createAlias或createCriteria（如here）进行修复，以便执行所需的联接。我正在做它并且它有效，但我错过了一些背景：

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

关于连接类型，没有歧义：它必须是INNER JOIN，否则平等无法保持，对吧？

Answer 1

关于为什么某些东西按照它的方式构建的问题总是很棘手，你可能需要直接向作者询问它。

我无法找到任何关于此的官方文档，但我认为它与基于字符串的查询（HQL）和基于对象的查询（标准）有关。

您编写的查询无论如何都比标准更多的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)
 ...

对于大多数查询，上面的方法是一个不必要的开销，并使代码不太可读恕我直言（我个人觉得HQL / JPQL更易读，即使涉及StringBuilder或类似），但我认为这是背后的基本思想标准：更安全，更可重复使用的查询部分。

Answer 2

关于连接类型，没有歧义：它必须是INNER JOIN，否则平等无法保持，对吧？

你应该使用INNER JOIN。

为什么它会像这样工作？

因为hibernate生成，所以你应该添加别名。

您是否考虑过Hibernate Native SQL？因为对数据库会有一个混乱的查询。

Hibernate嵌套属性条件

2 个答案: