Understanding of TABLE_PER_CLASS with keys in ecli

2019-09-01 08:11发布

问题:

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

Following classes:

@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;
}

In persistence.xml I do Drop&Create.

After creating the database, I have this tables:

abstractservice, service, persongroup

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

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.

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

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

With CriteriaBuilder I say:

Select from AbstractService where persongroup_id = 123;

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;

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...

回答1:

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.

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.