通过eclipselink中的键了解TABLE_PER_CLASS [英] Understanding of TABLE_PER_CLASS with keys in eclipselink

问题描述

我有一个带有Eclipselink和TABLE_PER_CLASS继承策略的简单Java EE 7 Web应用程序.

I have a simple Java EE 7 Web App with Eclipselink and the TABLE_PER_CLASS inheritance strategy.

以下课程:

@Inheritance(strategy = InheritanceType.TABLE_PER_CLASS)
@Entity
public abstract class AbstractService implements Serializable {
    private static final long serialVersionUID = 7041207658121699813L;
    @Id
    @GeneratedValue(strategy = GenerationType.AUTO)
    private Long id;
    @ManyToOne
    @JoinColumn
    private PersonGroup personGroup;
}

@Entity
public class Service extends AbstractService implements Serializable {
    private static final long serialVersionUID = 3817106074951672799L;
}

@Entity
public class PersonGroup implements Serializable {
    private static final long serialVersionUID = 3205092801888510996L;
    @Id
    @GeneratedValue(strategy = GenerationType.AUTO)
    private Long id;
    @OneToMany(cascade = CascadeType.ALL, mappedBy = "personGroup")
    private List<AbstractService> services;
}

在persistence.xml中，我进行拖放创建.

In persistence.xml I do Drop&Create.

创建数据库后，我有以下表格:

After creating the database, I have this tables:

抽象服务，服务，人员组

abstractservice, service, persongroup

现在要说的是，eclipselink使用(仅(！))属性persongroup_id(没有"id"属性)创建了表abstractservice.为什么?

The point is now, that eclipselink creates the table abstractservice with (only(!)) the attribute persongroup_id (no "id" attribute). Why?

我对TABLE_PER_CLASS的理解是，每个属性和键都在下降"，因此abstractservice应该没有更多属性，并且不应该存在.

My understanding from TABLE_PER_CLASS is, that every attribute and key is going "down", so abstractservice should have no more attributes and should not exist.

我的业务情况是，我有很多AbstractService的子服务.我想通过特殊的人员组从AbstractService获取所有子服务.

My businesscase is, that I have a lot of subservice from AbstractService. I want to get all subservices from AbstractService with a special persongroup.

AbstractServicetable没有条目，因为所有内容都在服务中.

The AbstractServicetable has no entries, because everything is in Service.

对于CriteriaBuilder，我说:

With CriteriaBuilder I say:

Select from AbstractService where persongroup_id = 123;

标准Api"应该构建此文件(如果存在更多子服务，则需要进行一些联合)，因为我有TABLE_PER_CLASS:

The Criteria Api should build this (with some union, if more subservices would exist), because I have TABLE_PER_CLASS:

Select from Service where persongroup_id = 123;

为什么eclipselink在abstractService中创建persongroup_id，如何解决我的情况? 最后，查询结果始终为空，因为abstractService为空...

Why is eclipselink creating persongroup_id in abstractService and how can I solve my case? At the end the result of the query is always empty, because abstractService is empty...

推荐答案

在此处提出了相同的问题: http://www.eclipse.org/forums/index.php/t/406338/ 似乎与错误 https://bugs.eclipse.org/bugs/有关show_bug.cgi?id = 265702 ，该问题已修复但已回归.如果您在最新版本中看到此错误，则应为其提交新的错误.

Same question was asked here: http://www.eclipse.org/forums/index.php/t/406338/ and seems to be related to bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=265702 which was fixed but regressed. A new bug should be filed for it if you are seeing this in the latest version.

如果仅使用单个Servide子类，则可能需要使其成为一个mappingSuperclass.如果不是，通常建议使用其他继承类型，例如联接表或单个表.该错误似乎仅影响DDL的生成，因此您可以切换为让JPA创建脚本，然后可以对其进行编辑以删除AbstractService表条目.

If you are only using a single Servide subclass, you might want to make it a mappedSuperclass instead. If not, a different inheritance type such as joined or single table is usually recommended. This bug seems to only affect DDL generation, so you can switch to have JPA create a script that you can then edit to remove the AbstractService table entries.

这篇关于通过eclipselink中的键了解TABLE_PER_CLASS的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！