// This subclass does not define its own table, but share its parent's ACCOUNT table.

+

// This subclass does not define its own table, but shares its parent's ACCOUNT table.

@Table(name="ACCOUNT")

@Table(name="ACCOUNT")

@DiscriminatorValue("3")

@DiscriminatorValue("3")

Line 413:

Line 413:

===Outer Joining Subclasses===

===Outer Joining Subclasses===

−

shouldOuterJoinSubclasses

+

EclipseLink supports two mechanism for reading <code>JOINED</code> inheritance classes. If you query to root or branch of a <code>JOINED</code> inheritance hierarhcy by default EclipseLink will query each concrete subclass separately and union the results in memory. This is normally the most efficient mechanism, but this depends on the database and configuration. If an order by is used, or joining, then EclipseLink will outer join all of the subclass tables in a single query.

+

+

To configure that an outer join always be used to query inheritance, a <code>DescriptorCustomizer</code> can be used to configure a <code>ClassDescriptor</code>'s <code>InheritancePolicy</code> using the API <code>setShouldOuterJoinSubclasses</code>. This can also be configured for a specific query using the <code>"eclipselink.inheritance.outer-join"="true"</code> query hint.

+

+

======''Example: Configuring <code>JOINED</code> inheritance to use an outer join''======

+

<source lang="java">

+

@Entity

+

@Table(name="ACCOUNT")

+

@Inheritance(strategy=InheritanceType.JOINED)

+

@DiscriminatorColumn(name="ACCOUNT_TYPE")

+

@Customizer(AccountCustomizer.class)

+

public class Account implements Serializable {

+

@Id

+

private Long id;

+

@Basic

+

private String balance;

+

...

+

}

+

</source>

+

+

<source lang="java">

+

public class AccountCustomizer implements DescriptorCustomizer {

+

public void customize(ClassDescriptor descriptor) {

+

descriptor.getInheritancePolicy().setShouldOuterJoinSubclasses(true);

+

}

+

}

+

</source>

===Reading Concrete Superclasses===

===Reading Concrete Superclasses===

−

shouldReadSubclasses

+

By default, when you query for a superclass, any valid subclass instances are also returned. This is normally correct, and desired, but sometimes only the root or branch class instances are desired.

+

For only a single query, this can be part of the query where clause using the JPQL <code>TYPE</code> function. If all queries desire only the superclass, then this can be configured in EclipseLink by customizing the descriptor.

+

+

To configure that queries for a superclass not return subclasses, a <code>DescriptorCustomizer</code> can be used to configure a <code>ClassDescriptor</code>'s <code>InheritancePolicy</code> using the API <code>setShouldReadSubclasses</code>.

+

+

Another option in JPA is to make the superclass abstract and create another subclass to store the concrete instances.

+

+

======''Example: Configuring account to not read subclasses''======

+

<source lang="java">

+

@Entity

+

@Inheritance(strategy=InheritanceType.JOINED)

+

@DiscriminatorColumn(name="ACCOUNT_TYPE")

+

@Customizer(AccountCustomizer.class)

+

public class Account implements Serializable {

+

@Id

+

private Long id;

+

@Basic

+

private String balance;

+

...

+

}

+

</source>

+

+

<source lang="java">

+

public class AccountCustomizer implements DescriptorCustomizer {

+

public void customize(ClassDescriptor descriptor) {

+

descriptor.getInheritancePolicy().setShouldReadSubclasses(false);

+

}

+

}

+

</source>

===Avoiding Inheritance===

===Avoiding Inheritance===

+

JPA requires that any persistent subclass inherit the persistence meta data from its superclass, if the superclass is a persistent entity. If you have a subclass, that does not want to inherit its persistence, this can be difficult.

+

+

One solution is to not define the superclass as an entity, but instead map it as a <code>MappedSuperclass</code>, see [[EclipseLink/UserGuide/JPA/Basic JPA Development/Entities/MappedSuperclass|@MappedSuperclass]].

+

+

Another solution is to not map the superclass as an entity. This then allows each subclass to define its own persistence. An orm XML file can be used to define mappings for the inherited attributes.

+

+

<code>TABLE_PER_CLASS</code> inheritance may also be used to avoid a common table.

+

+

EclipseLink allows for a subclass to be mapped independently of its superclass. This can be done using a <code>SessionCustomizer</code> and adding a complete <code>RelationalDescriptor</code> for the subclass.

===Interfaces===

===Interfaces===

+

EclipseLink has support for interfaces as well as inheritance. See [[EclipseLink/UserGuide/JPA/Advanced JPA Development/Interfaces|Interfaces]] for more information on interfaces.

@Inheritance

You can use the @Inheritance annotation or <inheritance> XML element to configure how entities with inheritance are persisted.
JPA defines three inheritance strategies SINGLE_TABLE, JOINED, and TABLE_PER_CLASS. By default the SINGLE_TABLE strategy is used and all of the subclasses are persisted in a single table that contains all of the column of all of the subclasses. In addition a discriminator column named DTYPE is required in the table to store the class type.

strategy – By default, the EclipseLink persistence provider assumes that all the classes in a hierarchy are mapped to a single table differentiated by the discriminator value (see @DiscriminatorValue) in the table's discriminator column (see @DiscriminatorColumn): InheritanceType.SINGLE_TABLE.If this is not appropriate for your application or if you must match an existing data model, set strategy to the desired InheritanceType enumerated type:

SINGLE_TABLE – all the classes in a hierarchy are mapped to a single table. The table has a discriminator column (@DiscriminatorColumn) whose value (@DiscriminatorValue) identifies the specific subclass to which the instance that is represented by the row belongs.

Note: This option provides the best support for both polymorphic relationships between entities and queries that range over the class hierarchy. The disadvantages of this option include the need to make nullable columns that should be NOT NULL.

TABLE_PER_CLASS – each class is mapped to a separate table. All properties of the class, including inherited properties, are mapped to columns of the table for the class.

Note: This option has several limitations when querying or having relationships to the root or branch classes. Joins to root or branch classes are not supported.

JOINED – the root of the class hierarchy is represented by a single table and each subclass is represented by a separate table. Each subclass table contains only those fields that are specific to the subclass (not inherited from its superclass) and primary key columns that serve as foreign keys to the primary keys of the superclass table. The join from the primary table to the subclass table can be configured using the @PrimaryKeyJoinColumn, see SecondaryTable for more info. If you have multiple levels of inheritance, each subclass table should join with the root table, and the discriminator column is only defined once in the root table.

For more information, see Section 9.1.29 "Inheritance Annotation" in the JPA Specification.

@DiscriminatorColumn

You can use the @DiscriminatorColumn annotation or <discriminator-column> XML element to configure the name or type of the inheritance discriminator column. The discriminator column is required for SINGLE_TABLE and JOINED inheritance and stores the associated entity type for the row. The default name for the discriminator column is DTYPE. JPA only allows String or Integer values for discriminators. Through the EclipseLink API, it is possible to use other discriminator types, and it is possible to not have a discriminator, or use custom discriminator, see Advanced Inheritance Configuration.

@DiscriminatorColumn Attributes

Attribute

Description

Default

Required?

name

The name of column to be used to store the class discriminator value.

DTYPE

No

discriminatorType

The type of the discriminator value, defined in DiscriminatorType, one of STRING, INTEGER, and CHAR.

STRING

No

columnDefinition

Optional column description for use with DDL generation.

generated base on discriminatorType

No

length

The size of the column for DDL generation. Only relevant for STRING types.

31

No

For more information, see Section 11.1.10 "DiscriminatorColumn Annotation" in the JPA Specification.

@DiscriminatorValue

You can use the @DiscriminatorValue annotation or <discriminator-value> XML element to configure the value of the inheritance discriminator. The discriminator value can be specified in each non-abstract class in the inheritance hierarchy. By default the discriminator value is the entity's name, which defaults to its unprefixed class name. The discriminator value is always specified as a String, but is converted to the discriminator column type.

The following examples shows usages of the three different inheritance strategies for mapping an Account hierarchy.

Advanced Inheritance Configuration

Mixed Inheritance

JPA requires the inheritance strategy to only be defined in the root class. If you want to use a mixture of SINGLE_TABLE and JOINED
this can be achieved through using JOINED inheritance in the root class, and specifying the Table on the subclass to be the same as the parent.

Example: Using JOINED with mixed inheritance

@Entity// This subclass does not define its own table, but shares its parent's ACCOUNT table.
@Table(name="ACCOUNT")
@DiscriminatorValue("3")publicclass StandardAccount extends Account {
...
}

@ClassExtractor

If you are mapping to an existing database, and the tables do not have a discriminator column you can still define inheritance using the EclipseLink @ClassExtractor or class-extractor XML element. The class extractor takes a class that implements the ClassExtractor interface. EclipseLink uses a instance of this class to determine the class type to use for a database row. The class extractor must define a extractClassFromRow method that takes the database Record and EclipseLink Session.

If a class extractor is used with SINGLE_TABLE inheritance, EclipseLink needs to be able to filter the rows of the class type in queries. This can be accomplished in EclipseLink through setting an onlyInstancesExpression or withAllSubclassesExpression for branch classes. These can be set to EclipseLink Expression objects using a DescriptorCustomizer.

Using Other Discriminator Types

JPA only defines three discriminator types, STRING, CHAR, and INTEGER. EclipseLink allows for any database type to be used for a discriminator. To define discriminators using other types a DescriptorCustomizer can be used to customize the discriminators in the ClassDescriptor's InheritancePolicy using the addClassIndicator API.

Example: Using a DiscriminatorColumn with a boolean type do define inheritance

Outer Joining Subclasses

EclipseLink supports two mechanism for reading JOINED inheritance classes. If you query to root or branch of a JOINED inheritance hierarhcy by default EclipseLink will query each concrete subclass separately and union the results in memory. This is normally the most efficient mechanism, but this depends on the database and configuration. If an order by is used, or joining, then EclipseLink will outer join all of the subclass tables in a single query.

To configure that an outer join always be used to query inheritance, a DescriptorCustomizer can be used to configure a ClassDescriptor's InheritancePolicy using the API setShouldOuterJoinSubclasses. This can also be configured for a specific query using the "eclipselink.inheritance.outer-join"="true" query hint.

Reading Concrete Superclasses

By default, when you query for a superclass, any valid subclass instances are also returned. This is normally correct, and desired, but sometimes only the root or branch class instances are desired.
For only a single query, this can be part of the query where clause using the JPQL TYPE function. If all queries desire only the superclass, then this can be configured in EclipseLink by customizing the descriptor.

To configure that queries for a superclass not return subclasses, a DescriptorCustomizer can be used to configure a ClassDescriptor's InheritancePolicy using the API setShouldReadSubclasses.

Another option in JPA is to make the superclass abstract and create another subclass to store the concrete instances.

Avoiding Inheritance

JPA requires that any persistent subclass inherit the persistence meta data from its superclass, if the superclass is a persistent entity. If you have a subclass, that does not want to inherit its persistence, this can be difficult.

One solution is to not define the superclass as an entity, but instead map it as a MappedSuperclass, see @MappedSuperclass.

Another solution is to not map the superclass as an entity. This then allows each subclass to define its own persistence. An orm XML file can be used to define mappings for the inherited attributes.

TABLE_PER_CLASS inheritance may also be used to avoid a common table.

EclipseLink allows for a subclass to be mapped independently of its superclass. This can be done using a SessionCustomizer and adding a complete RelationalDescriptor for the subclass.

Interfaces

EclipseLink has support for interfaces as well as inheritance. See Interfaces for more information on interfaces.