关于@ForceDiscriminator/@DiscriminatorOptions的使用（力=真）

由于我一遍又一遍地讨论这个问题，我认为它可能有助于澄清：首先，Hibernate在使用映射时确实不需要歧视。但是，在使用 时确实需要它。更重要的是，其他 JPA 提供程序大多确实需要它。JOINED_TABLESINGLE_TABLE

在执行多态查询时，Hibernate 的实际操作是创建一个动态命名的鉴别器，使用大小写开关，在对继承树中涉及的所有表进行外联接后，检查是否存在具体子类唯一的字段。在 .在我看来，这可能是查询的完美解决方案，所以Hibernate的人吹嘘它是正确的。JOINED_TABLEclazz"hibernate.show_sql"persistence.xmlJOINED_TABLE

执行更新和删除时，情况有所不同;在这里，休眠首先查询根表以查找与语句的 where 子句匹配的任何键，并从结果创建一个虚拟。然后，它使用继承树对任何具体类执行 a;IN 运算符会对扫描的每个表条目产生一个子查询，但它很可能在内存中，因此从性能角度来看，它并不是太糟糕。pkTable"DELETE FROM / UPDATE table WHERE pk IN pkTable"O(log(N))

为了回答你的具体问题，Hibernate在这里根本没有看到问题，从某种角度来看，它们是正确的。对于他们来说，通过在 期间注入鉴别值来简单地遵守注释是非常容易的，即使他们实际上并没有使用它们。但是，不尊重中的鉴别器列具有（对于Hibernate）创建轻微的供应商锁定情况的优势，甚至可以通过指向高级技术来辩护。@DiscriminatorValueentityManager.persist()JOINED_TABLE

@ForceDiscriminator或者肯定有助于减轻一点痛苦，但是您必须在创建第一个实体之前使用它们，或者被迫使用SQL语句手动添加缺少的鉴别器值。如果你敢于离开Hibernate，它至少需要你一些代码更改来删除这些Hibernate特定的注释，从而对迁移产生阻力。在这种情况下，这显然是Hibernate所关心的。@DiscriminatorOptions(force=true)

根据我的经验，供应商锁定是每个市场领导者最疯狂的梦想的天堂，因为它是马基雅维利式的魔杖，毫不费力地保护市场份额;因此，每当客户不反击并迫使供应商定价高于所获得的利益时，就会这样做。谁说开源世界会有什么不同？

p.s，为了避免任何混淆：我绝不隶属于任何JPA实现者。

p.p.s：我通常做的是忽略问题，直到迁移时间;然后，您可以使用与 Hibernate 相同的大小写切换与外连接技巧来填充缺少的鉴别器值来制定语句。一旦你理解了基本原理，这实际上很容易。SQL UPDATE ... FROM

伙计们让我试着解释一下。好吧，它用于单个表继承，我最近在其中一个场景中使用了它。我有两个实体映射到单个表。当我尝试获取一个实体的记录时，我从两个实体中获取结果包含记录的列表，这是我的问题。为了解决这个问题，我已经使用了它将使用鉴别器列创建谓词，其指定值映射到相应的实体。所以查询在我使用后会看起来像这样@DiscriminatorOptions(Force=true)@DiscriminatorOptions(Force=true)@DiscriminatorOptions(Force=true)

select * 
from TABLE 
where  YOUR PREDICATE AND DiscriminatorColumn = DiscriminatorValue