【问题标题】:Why EclipseLink is adding discriminator column for joined inheritance strategy?为什么 EclipseLink 为联合继承策略添加鉴别器列?
【发布时间】:2010-01-14 10:44:59
【问题描述】:

我正在使用 EclipseLink JPA 实现的 JOINED 继承策略。我注意到 EclipseLink 正在将默认 DTYPE 命名的鉴别器列添加到数据库模式中。我知道,一个表继承策略需要该鉴别器,但为什么要使用 JOINED 策略?

EclipseLink 需要这个专栏,因为我在删除它后遇到了错误。是否出于性能原因等原因添加了此列?我对此并不特别高兴,因为从数据库架构的角度来看,这个专栏只是不必要的混乱。

基于 Hibernate 的 JPA 不会做任何类似的事情。

【问题讨论】:

  • 也许您的问题有误。你说你明白为什么如果它加入但不如果它加入......

标签: jpa eclipselink


【解决方案1】:

来自Joined Table Inheritance

在连接表继承中,每个 类共享根表中的数据。 此外,每个子类都定义了它的 自己的表,增加了它的扩展 状态。下面的例子展示了两个 表,PROJECT 和 L_PROJECT,以及 作为两个类,项目和 大型项目:

...

鉴别器列决定了类型,因此决定了要使用的连接表,因此您需要父表中的鉴别器列。

【讨论】:

  • 没错,这就是我想了解的:为什么 EclipseLink 使用这个鉴别器列 - 没有必要,JOINED 策略是基于类之间的外键关联。 JPA 规范说鉴别器对于 JOINED 策略是可选的 - 例如 Hibernate JPA 没有使用它 - 我想了解使用它的优势是什么,就像 EclipseLink 一样。
  • 我猜你指的是docs.jboss.org/hibernate/core/3.3/reference/en/html/…。我猜 ExlipseLink 在这方面是明确的。鉴别器列避免了执行 EXISTS(或类似)检查以找到适当的子类的问题。即使它是可选的,我仍然会使用它。
  • 这是有道理的,鉴别器肯定会让事情更容易实现。谢谢你的回答!
  • 同意 - EclipseLink 肯定需要一个鉴别器列以更轻松地实现库。很高兴看到 Hibernate 解决方案的一些性能基准(它将“只是”一些 CASE WHEN ... 添加到 SELECT 中) - 与使用鉴别器列相比,它是否真的更多慢。无论如何,这个 SO 答案不能被标记为真正有用 - 它只是描述了被问到的内容。可惜 EL 没有这个功能 - 至少,它肯定会简化一些“遗留”应用程序的迁移。
  • 如果您无法更改数据模型并已加入继承并且您需要加入继承怎么办?然后整个查询失败,出现一些错误Unknown column 't0.DTYPE' in 'field list' Error Code: 1054 Call: SELECT t0.ID, t0.DTYPE, t0.NAME, t0.parent_id, t1.ID FROM GeoAreas t0, Districts t1 WHERE ((t0.ID = ?) AND ((t1.ID = t0.ID) AND (t0.DTYPE = ?))) ...,你基本上可以马上忘记 EclipseLink……这不应该被修复吗?
猜你喜欢
  • 2014-04-20
  • 2019-02-17
  • 2011-04-08
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2011-12-02
相关资源
最近更新 更多