Category: JPA/Hibernate

Often you don’t want to map all relationships in an entity model (a blog post about this topic in detail will follow).

Let’s have a look at this class diagram:

There is no mapping between PurchaseOrder and PurchaseOrderItem because there is no use case for this relationship. Either we want to read all orders or we want to display all items of an order but we never want to have all orders with all items.

On the database, we have for sure the foreign key that stores the PurchaseOrder ID on the PurchaseOrderItem table. So we just map the purchaseOrderId in the PurchaseOrderItem entity:

@Entity
public class PurchaseOrderItem {

    @Id
    @GeneratedValue
    private Integer id;
    private Integer purchaseOrderId;
    @ManyToOne
    private Product product;

// Getters/Setters and more ...
}

Now if we need to join the two tables anyway for example in an aggregation to get the sum of the item price, we can do that because of the JPA 2.1 extension JOIN ON:

SELECT NEW entity.PurchaseOrderInfo(p.id, sum(i.product.price))
FROM PurchaseOrder p
JOIN PurchaseOrderItem i ON p.id = i.purchaseOrderId
GROUP BY p.id

This is supported in EclipseLink and Hibernate >= 5.1.

Relational databases have tables and columns and object-oriented programming languages have classes and fields but they also provide inheritance.

Relational databases have tables and columns and object-oriented programming languages have classes and fields but they also provide inheritance. A concept that is not known in relational databases.

JPA provides solutions to map inheritance to database tables but by default, JPA doesn’t care about inheritance and will not map any fields from a superclass to the database.

You always have to define how inheritance should be handled. JPA distinct two scenarios:

Scenario 1: Mapped Superclass

Often you want to define fields and/or behavior in a common superclass like a timestamp when the entity was created:

Unless you don’t define how this should be handled, JPA will not consider the field createdAt when persisting the Address entity.

To tell JPA to include the fields of a superclass in the mapping you have to use the MappedSuperclass annotation:

@MappedSuperclass
public class BaseEntity {
    private Timestamp createdAt;
}

@Entity
public class Address extends BaseEntity {
}

In that case, JPA assumes that the database table Address contains a column with the name createdAt.

Scenario 2: Mapping Inheritance

Let’s assume that we have the following inheritance hierarchy:

The Employee class is abstract and has a field name, whereas FulltimeEmployee doesn’t have its own fields but ParttimeEmployee has a field that defines the percentage he works for the company.

But how can we map this with JPA? Let’s have a look at what the specification says:
http://download.oracle.com/otndocs/jcp/persistence-2_1-fr-eval-spec/index.html

2.12 Inheritance Mapping Strategies

The mapping of class hierarchies is specified through metadata.

There are three basic strategies that are used when mapping a class or class hierarchy to a relational database:

• a single table per class hierarchy
• a joined subclass strategy, in which fields that are specific to a subclass are mapped to a separate table than the fields that are common to the parent class, and a join is performed to instantiate the subclass.
• a table per concrete entity class

An implementation is required to support the single table per class hierarchy inheritance mapping strategy and the joined subclass strategy.

Support for the table per concrete class inheritance mapping strategy is optional in this
release. Applications that use this mapping strategy will not be portable.

Support for the combination of inheritance strategies within a single entity inheritance hierarchy is not required by this specification.

Metadata

To activate inheritance we have to add the Inheritance annotation to the base class Employee:

@Inheritance
@Entity
public abstract class Employee {
    @Id
    private Integer id;
    private String name;
}

@Entity
public class FulltimeEmployee extends Employee {
}

@Entity
public class ParttimeEmployee extends Employee {
    private int percentage;
}

Database Representation

OK…. but what do the database tables look like?

The Inheritance annotation has an attribute strategy of type InheritanceType. There are three inheritance types as described in the spec: SINGLE_TABLE, JOINED, TABLE_PER_CLASS.

SINGLE_TABLE

The default strategy is SINGLE_TABLE and would look like this:

As you can see all attributes of the whole inheritance hierarchy are flattened to a single table. Additionally, a column dtype was added. (The column name is not defined in the specification and is, therefore, implementation-dependent.) This column indicates which class must be instantiated when loading the data from the database.

The advantage of this strategy is that it’s easy to use even if the user directly uses the database and doesn’t know about inheritance in the entity model.

But there is also a disadvantage. Have a look at the column percentage. The N indicates that this column is nullable. But wait a ParttimeEmployee must always have a percentage! That’s not possible because the other subtype of Employee FulltimeEmployee doesn’t have this field.

So if you have mandatory fields in subclasses SINGLE_TABLE is probably not the best strategy.

JOINED

The JOINED strategy will create a table for every class in the hierarchy:

This looks like our class diagram, doesn’t it? The id is inherited means that for every instance of either FulltimeEmployee or ParttimeEmployee we will have a record in the Employee table and the primary key of Employee will be the primary and the foreign key in the FulltimeEmployee or ParttimeEmployee table.

And in contrast to the SINGLE_TABLE strategy, the percentage column in the ParttimeEmployee is now not nullable!

Perfect, but is there a disadvantage? Yes, the JPA implementation could always join the tables and this could be slower than the SINGLE_TABLE strategy. But this depends on the database and the indexes that are set on the tables.

Also querying the database with plain SQL could also be a bit more complicated because you have to do the same joins that the JPA implementation would do to get all the data.

TABLE_PER_CLASS

The last strategy is called TABLE_PER_CLASS because there is only a table if the Entity class is not abstract. In our example, the table Employee is missing because the class Employee is abstract.

In the first place, this strategy looks pretty good as it also allows to have the percentage column not nullable in the database table. But the disadvantage is when you query on the superclass level Employee then it has to execute two queries or do a union of FulltimeEmployee and ParttimeEmployee which could lead to a performance issue.

Conclusion

If you are using inheritance with JPA you can choose between the mapped superclass to have all fields of the superclass in the database table of the entity or to use “real” inheritance with one of the three inheritance strategies.

In my opinion, the TABLE_PER_CLASS strategy is not useful and with the disadvantage of multiple queries or a union probably the slowest option.

Choose SINGLE_TABLE when your subclass has only a few fields that are not mandatory. Also, choose this option when you use the database not only with JPA but also with plain SQL because this has the simplest model for querying.

In all other cases go for the JOINED strategy.

With JPA it’s possible to map Java enums to columns in a database table using the Enumerated annotation.

@Enumerated
private Color color;    

An enum can be mapped as an integer or a string but mapping of enums that contain state is not supported.

EnumType.ORDINAL

The default mapping is using an integer that represents the ordinal value of the enum value. The ordinal value is created at compile time based on the position of the enum value.

Let’s have a look at an example enum Color

public enum Color {
    RED, GREEN, BLUE
}

Enum is a Java compile time construct that means the enum is translated in a class.

This is how Color looks after decompiling:

public final class Color extends Enum {

    public static Color[] values() {
        return (Color[])$VALUES.clone();
    }

    public static Color valueOf(String name) {
        return (Color)Enum.valueOf(com/example/demo/Color, name);
    }

    private Color(String s, int i) {
        super(s, i);
    }

    public static final Color RED;
    public static final Color GREEN;
    public static final Color BLUE;
    private static final Color $VALUES[];

    static {
        RED = new Color("RED", 0);
        GREEN = new Color("GREEN", 1);
        BLUE = new Color("BLUE", 2);
        $VALUES = (new Color[] {
            RED, GREEN, BLUE
        });
    }
}

As you can see RED has the value 0, GREEN 1 and BLUE 2.

But imagine what will happen if we change the enum Color like this:

public enum Color {
    YELLOW, RED, GREEN, BLUE
}    

Now the ordinal values are all changed! This means you have to migrate your database and if you don’t do this you will have wrong values!

To conclude using the ordinal value is a dangerous idea and I don’t understand why the JPA expert group decided to define this as the default behavior.

So how to solve this issue?

EnumType.STRING

We can define the mapping to use the string representation of the enum instead of the ordinal value:

@Enumerated(EnumType.STRING)
private Color color;

Like this JPA will store RED, GREEN and BLUE in the column of the database table and this resolves the problem when adding new enum values or changing the order of existing ones.

But if we change the name of the enum value itself we still have to do a database migration.

The problem with enums is that there is no representation of the allowed values in the database. So your application is responsible to only allow valid values to be inserted in the database table.

But what happen when someone is adding a value directly in the database table that is not valid? For example I added a record in the table with the color BLACK and now Hibernate is complaining:

java.lang.IllegalArgumentException: Unknown name value [BLACK] for enum class [Color]

To avoid this problem we could add a check constraint to the database table:

CREATE TABLE Cars (
    color VARCHAR(20)
    CHECK (color IN ('RED', 'GREEN', 'BLUE'))
);

This would solve the problem but you see what happened? We have code duplication!

RED, GREEN and BLUE are defined in the enum and in the database as well and now we have to make sure to always change both artifacts the enum and the table.

Are Enums with JPA an Antipattern?

Bill Karwin wrote in his highly recommended book SQL Antipatterns: Avoiding the Pitfalls of Database Programming in “Chapter 11.31 Flavors” about the same problem when using enum like types in database tables.

I fully agree with his final statement:

Use metadata (in our case enums) when validating against a fixed set of values (that never change).

Use data when validating against a fluid set of values.

Think twice when you use an enum with JPA.